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ARI  Research  Reports  and  Technical  Reports  are  intended  for  sponsors  of 
R&D  tasks  and  for  other  research  and  military  agencies.  Any  findings  ready 
for  implementation  at  the  time  of  publication  are  presented  in  the  last  part 
of  the  Brief.  Upon  completion  of  a  major  phase  of  the  task,  formal  recom¬ 
mendations  for  official  action  normally  are  conveyed  to  appropriate  military 
agencies  by  briefing  or  Disposition  Form. 


FOREWORD 


The  Human  Factors  Technical  Area  of  the  Army  Research  Institute  is  con¬ 
cerned  with  aiding  users/operators  to  cope  with  the  ever-increasing  complexity 
of  the  man-machine  systems  being  designed  to  acquire,  transmit,  process,  dis¬ 
seminate,  and  utilize  tactical  information  on  the  battlefield.  The  research 
is  focused  on  the  interface  problems  and  interactions  within  command  and  con¬ 
trol  centers  and  is  concerned  with  such  areas  as  tactical  symbology,  user 
oriented  systems,  information  management,  staff  operations  and  procedures, 
systems  integration  and  utilization  as  well  as  issues  of  system  development. 

An  area  of  special  concern  is  the  development  of  procedures  for  effective 
system  control  and  utilization.  The  inevitable  need  for  engineering  tradeoffs 
during  system  design  often  results  in  systems  which  are  unmanageable  or  which 
at  best  achieve  only  a  small  portion  of  their  potential.  Explicit  attention 
to  the  procedures  to  be  followed  by  the  user  can  compensate  for  some  of  these 
problems,  particularly  if  accomplished  early  enough  in  the  development  cycle. 

The  present  publication  is  one  of  several  from  a  project  with  an  initial  focus 
on  the  Tactical  Operations  Systems  (TOS)  and  an  initial  goal  of  the  development 
of  procedures  for  managing  the  flow  of  information  in  TOS.  The  present  report 
reflects  the  redirection  of  the  TOS  development  program,  and  provides  guide¬ 
lines  for  managing  information  flow  in  automated  battlefield  systems  in  gen¬ 
eral.  These  guidelines  and  accompanying  analyses  establish  the  basis  for 
definition  and  implementation  of  management  procedures  in  a  variety  of  infor¬ 
mation  processing  systems. 

Research  in  the  area  of  information  management  is  conducted  as  an  in-house 
effort  augmented  through  contracts  with  organizations  selected  for  their  unique 
capabilities  and  facilities  for  research  in  this  area.  The  present  study  was 
conducted  by  personnel  from  Vector  Research  Inc.  under  contract  DAHC19-78-C-0027 
and  directed  by  Dr.  Stanley  M.  Halpin  and  Mr.  Robert  S.  Andrews.  This  effort 
is  responsive  to  requirements  of  Army  Project  2Q163739A793  and  to  the  Combined 
Arms  Combat  Development  Activity,  Fort  Leavenworth,  Kans.,  and  Communications 
R&D  Command  (CORADOCOM),  Fort  Monmouth,  N.J.  Special  requirements  are  con¬ 
tained  in  Human  Resources  Need  80-305,  Information  Management  Within  the  Tacti¬ 
cal  Operations  System. 


JOlSEPH  ZSJfDNER 
Technical  Director 


GUIDELINES  FOR  MANAGING  THE  FLOW  OF  INFORMATION  IN  AN  AUTOMATED  BATTLEFIELD 
COMMAND  AND  CONTROL  SYSTEM 


I 

BRIEF 


Requirement : 

This  part  of  a  project  to  develop  information  management  concepts  and 
procedures  for  automated  battlefield  command  and  control  systems  (ABCCS)  was 
intended  to  describe  how  design  parameters  of  contemporary  ABCCS  can  affect 
other  system  management  tasks,  and  to  provide  (a)  procedures  for  managing 
ABCCS  and  (b)  methods  and  monitoring  statistics  needed  to  manage  field 
operations • 


Procedure  s 

A  congestion  analysis  of  TOS  (a  specific  command  and  control  system)  and 
its  supporting  communications  parameters  indicated  specific  upper  limits  on 
the  utilization  of  any  component  (80%  of  full  capacity).  The  analysis  iden¬ 
tified  the  most  severe  specific  management  and  communications  problems  to  be 
expected  in  field  operations.  With  data  from  the  TOS  example,  management 
guidelines  were  developed  for  controlling  the  demand  on  components  and  prevent¬ 
ing  or  remedying  an  overload. 


Results: 

Management  procedures  effective  in  controlling  excessive  demands  on  com¬ 
puter,  communications,  and  user  are  (1)  control  of  the  number  of  incoming  mes¬ 
sage  retrieval  requests,  (2)  use  of  operating  levels,  (3)  purging  of  useless 
data,  (4)  removal  of  users  from  distribution  lists,  and  (5)  hierarchical  review. 

The  system  controller  can  detect  a  potential  overload  and  avoid  a  system 
crash  by  considering  the  interaction  of  (1)  the  responsiveness  required  of  the 
system,  (2)  the  methods  of  measuring  the  utilization  responsiveness  threshold, 
and  (3)  the  procedures  available  to  correct  the  problem. 


Utilization : 

These  guidelines  and  accompanying  analyses  establish  the  basis  for  defin¬ 
ing  and  implementing  management  procedures  in  a  variety  of  information  process¬ 
ing  systems. 
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PREFACE 


This  document  is  one  of  eight  reports  which  describe  the  work  performed 
by  Vector  Research,  Incorporated  (VRI)  and  its  subcontractor,  Perceptronics , 
Incorporated,  for  the  U.S.  Army  Research  Institute  for  the  Behavioral  and  So¬ 
cial  Sciences  (ARI)  under  the  second  phase  of  contract  number  DAHC19-78-C-0027. 
The  work  described  was  performed  over  12  months  of  an  anticipated  36-month 
three-phased  project.  The  overall  objective  of  the  project  has  been  to  pro¬ 
duce  procedural  guidelines  to  be  used  by  divisions  in  the  field  in  developing 
standard  operating  procedures  for  information  management  in  the  Tactical  Opera¬ 
tions  System  (TOS).  As  a  consequence  of  the  redirection  of  the  TOS  develop¬ 
ment  effort  in  November  1979,  the  objective  of  this  work  was  reinterpreted  to 
include  automated  battlefield  command  control  systems  (ABCCS)  in  general,  us¬ 
ing  TOS  for  an  explicit  example  of  the  design,  human  factors,  and  management 
control  considerations  which  must  be  addressed. 

The  VRI  study  team  for  phase  II  was  comprised  of  Dr.  Robert  W.  Blum 
(Project  Leader),  Ms.  Cathleen  A.  Callahan,  Dr.  W.  Peter  Cherry,  Mr.  Mark  G. 
Graulich,  Mr.  Donald  Kleist,  Mr.  Mark  Meerschaert,  Mr.  Greqory  Touma ,  and 
Mr.  Gary  Witus.  The  Perceptronics  team  for  phase  II  consisted  of  Dr. 

Michael  G.  Samet  and  Dr.  Ralph  E.  C-eiselman. 

The  authors  wish  to  acknowledge  the  helpful  contributions  of  Dr.  Stanley 
M.  Halpin  and  Mr.  Robert  Andrews,  who  were  charged  with  monitoring  the  study 
for  ARI;  and  LTC  L.  Walker,  MAJ  A.  Edmonds,  and  Mr.  M.  Carrio,  who  performed 
a  similar  function  for  that  portion  of  the  study  effort  which  was  jointly  spon¬ 
sored  with  ARI  by  the  U.S.  Army  Communications  Research  and  Development  Com¬ 
mand  (CORADCOM). 

The  eight  reports  are  as  follows: 

Blum  et  al..  Information  Management  for  an  Automated  Battlefield  Command 
and  Control  System:  Executive  Summary,  ARI  Research  Report  1249  — 
presents  an  overview  of  the  project  and  the  other  seven  reports. 

Callahan  et  al.,  Guidelines  for  Managing  the  Flow  of  Information  in  an 
Automated  Battlefield  Command  and  Control  System,  ARI  Research  Re¬ 
port  1248  —  describes  considerations  in  and  procedures  for  the 
management  of  contemporary  ABCC  systems. 

Geiselman  and  Samet,  Guideline  Development  for  Summarization  of  Tactical 
Data,  ARI  Technical  Report  458  --  an  analysis  of  procedures  for  the 
extraction,  summarization,  and  presentation  of  critical  information. 

Witus  et  al..  Analysis  of  Information  Flow  in  the  Tactical  Operations 
System  (TOS),  ARI  Research  Note  80-12  —  describes  the  purpose, 
approach,  and  results  of  a  TOS  analysis  which  focused  on  TOS  when 
integrated  with  a  planned  communications  support  system. 

Witus  et  al..  Description  of  the  Tactical  Operations  System  Information 
Flow  Model,  ARI  Research  Note  80-13  —  describes  t:he  representation 
of  TOS  used  to  develop  the  analysis  package  and  the  mathematics  of 
the  model. 


IX 
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Witus  et  al.,  User's  Manual  for  the  Tactical  Operations  System  Analysis 
Package,  ARI  Research  Note  80-14  —  explains  the  use  and  operation 
of  the  analysis  package. 

Witus  et  al.,  Programmer's  Manual  for  the  Tactical  (derations  System 
Analysis  Package,  ARI  Research  Note  80-15  —  describes  the  pro¬ 
gramming  details  of  the  package  to  facilitate  modifications  or 
transfer  between  host  systems. 

Cherry,  WP,  All  Source  Analysis  System:  Design  Issues,  ARI  Working 

Paper  HF80-XX  —  a  discussion  of  design  issues  associated  with  the 
emerging  ASAS  concept. 
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GUIDELINES  FOR  MANAGING  THE  FLOW  OF  INFORMATION  IN  AN  AUTOMATED 
BATTLEFIELD  COMMAND  AND  CONTROL  SYSTEM 


1.0  OVERVIEW 

This  report  of  the  project  described  in  the  preface  is  concerned  with: 

(1)  revision  and  expansion  of  the  provisional  SOP  guidelines  and  (2)  evalua¬ 
tion  methodology  and  criteria.  The  methodology  for  evaluating  the  guidelines 
was  planned  originally  (1978)  to  use  hardware  and  software  prototypes  in  a 
field  test  environment.  When  it  became  apparent  that  such  prototypes  would 
not  be  available  as  expected,  a  generic  automated  battlefield  command  and 
control  system  (ABCCS)  was  described  in  the  form  of  a  mathematical  model.  In 
order  to  use  that  model  to  study  the  Tactical  Operations  System  (TOS),  its 
parameters  were  quantified  from  the  developing  system  design  and  assumed  to 
be  representative  of  TOS  as  it  might  have  been  fielded.  The  evaluation  cri¬ 
teria  were  developed  jointly  with  the  TOS  communications  network  model.  As 
a  consequence  of  that  research,  the  revised  and  expanded  SOP  guidelines  were 
directed  toward  managing  and  controlling  the  demands  imposed  on  each  of  the 
system  components  so  as  to  avoid  overloading  any  of  them  or,  if  one  does 
become  overburdened,  to  reduce  the  demand  to  a  tolerable  operation  condition. 
The  principal  function  of  this  overview  chapter  is  to  summarize  the  reasoning 
which  led  to  the  guidelines  assuming  that  orientation. 

Automated  battlefield  command  and  control  systems  (ABCCS)  of  various 
types  are  being  developed  by  the  army  for  fielding  in  the  1980s.  Other  than 
TOS,  whose  development  was  arrested  by  congressional  action  in  November  1979, 
some  prominent  examples  of  contemporary  ABCCS  in  varying  stages  of  development 
are  TACFIRE  I,  ASAS,  and  ECS2.  When  imagining  such  a  system,  one  might  tend 
to  focus  solely  on  its  hardware  and  software,  but  such  a  view  would  be  unfor¬ 
tunately  myopic.  The  degree  to  which  the  operational  potential  of  any  ABCC 
system  is  achieved  depends  to  a  large  extent  on  the  degree  to  which  a  number 
of  extended  system  elements  are  recognized  (by  both  the  development  and  re¬ 
quirements  communities)  to  affect  the  system's  operation  and  are  treated 
accordingly.  These  system  elements  are: 

•  users  (operators,  subscribers,  and  managers/controllers); 

•  hardware  and  software? 

•  supporting  communications?  and 

•  tactical  and  physical  environments. 

Exhibit  1-1  illustrates  these  elements  of  an  extended  ABCC  system  in  which 
the  communications,  hardware  and  software,  and  users  are  jointly  embedded  in 
the  tactical  environment  which,  in  turn,  is  embedded  in  the  ambient  physical 
environment. 
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ABCC  systems  are  characteristically  automated,  but  not  automatic.  They 
interact  with  humans  (operators,  system  subscribers,  and  system  managers  or 
controllers).  Through  those  interactions,  ABCCS  pass  information  to  these 
system  users  and  receive  information  and  instructions  from  them.  An  inter¬ 
face  exists  between  the  system  and  the  system  users.  Part  of  that  interface 
may  be  deliberately  designed  during  the  development  process,  but  some  part  of 
it  can  usually,  if  not  always,  be  expected  to  be  an  implicit  consequence  of 
other  design  considerations  and  the  operational  environments. 

An  inevitable  fact  of  life  in  any  information  system  is  that  any  of  the 
system  components  are  subject  to  overload  and  subsequent  impaired  performance. 
The  overloads  may  occur  for  a  number  of  reasons: 

•  a  user/subscriber  is  overburdening  some  portion  of  the  system; 

•  the  tactical  environment  is  degrading  the  system's  capability  to 
perform; 

•  the  physical  environment  is  degrading  the  system’s  capability  to 
perform;  or 

•  the  system  is  overburdening  some  user-operator  or  user-subscriber. 

Each  of  the  above  situations  requires  some  form  of  management  control  and  is 
occasioned  by  the  capacity  of  some  component  of  the  extended  system  being  less 
than  sufficient  to  accommodate  the  demand  being  placed  upon  it.  Since  capacity 
is  a  system  characteristic  resulting  from  its  design  and  temporarily  fixed  by 
its  operating  environment,  it  cannot  be  changed  at  will.  Therefore,  the  burden 
on  the  component  (an  ABCC  hardware  component,  supporting  communications  compo¬ 
nent,  or  user — either  operator  or  subscriber)  being  overloaded  must  be  altered 
to  bring  demand  into  line  with  capacity  so  as  to  reduce  the  congestion  at  the 
problem  component. 

Setting  aside  for  the  moment  the  manager's  problem  of  identifying  the 
congested  component  needing  relief  and  assuming  that  the  identification  has 
been  made,  the  manager  must  be  judicious  in  selecting  the  means  to  relieve  the 
overload;  any  control  procedure  will  inevitably  alter  the  quantity  of  informa¬ 
tion  being  handled  by  the  congested  component  and,  therefore,  the  quantity  of 
information  available  to  the  ABCCS  users.  The  means  for  reducing  an  overload 
should  be  carefully  selected  to  ensure  that  the  quality  of  information  which 
results  is  not  unnecessarily  degraded  as  the  quantity  of  information  is  re¬ 
duced.  In  fact,  various  techniques  have  been  developed  in  the  field  of  in¬ 
formation  science  which  can  actually  increase  the  quality  of  a  corpus  of 
information  by  reducing  its  irrelevancies  and  other  inherent  obstacles  to 
its  easy  assimilation  by  a  user. 

For  managing  any  type  of  ABCC  system,  alternative  procedures  can  be  de¬ 
vised  for  controlling  the  quantity  of  information  handled  by  a  given  system 
component.  Each  alternative  will  have  more  or  less  effect  in  reducing  infor¬ 
mation  flow  because  each  alternative  is  fundamentally  oriented  toward  alter¬ 
ing  the  flow  of  information  due  to  a  unique  cause.  Some  examples  of  such 
causal  agents  in  TOS  would  be  excessive  message  input  or  output  traffic  at 
a  terminal  (analogous  to  a  Wall  Street  ticker  tape  running  well  behind  the 
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floor  transactions),  numerous  standing  requests  for  information  newly  entering 
the  data  base,  very  busy  communications  links,  and  undesirably  rapid  growth 
in  the  size  of  the  data  base.  Even  though  a  particular  procedure  might  have 
the  greatest  capability  for  directly  reducing  the  quantity  flow  of  information 
through  an  overloaded  component,  good  professional  judgment  might  suggest  that 
a  less  powerful  indirect  procedure  or  combination  of  procedures  should  be  em¬ 
ployed  instead.  Human  judgment  in  situ  is  essential  in  choosing  which  alter¬ 
natives  are  most  desirable  in  a  given  situation  for  maintaining  the  quality  of 
both  the  information  flow  and  the  data  base,  therein  making  the  tradeoffs  be¬ 
tween  quantity  and  quality  which  are  inherent  to  the  management  process.^-  Be¬ 
cause  of  the  importance  cf  quality  to  the  overall  worth  of  information,  each 
of  the  procedures  for  controlling  information  quantity  in  an  ABCCS  described 
in  this  report  is  accompanied  by  a  brief  discussion  of  the  general  quality 
considerations  which  may  be  attendant  to  a  decision  to  employ  that  procedure. 

Setting  aside  considerations  on  information  quality,  common  sense  tells 
us  that  selecting  a  management  control  procedure  for  altering  the  flow  of  in¬ 
formation  through  an  overburdened  system  component  requires  that  the  respon¬ 
sible  manager  be  able  to  discern  that  a  problem  exists  or,  preferably,  is 
about  to  exist,  where  it  exists,  and  why.  If  the  existence  of  an  overload 
problem  is  not  discernable  until  it  becomes  catastrophic  or  the  manager  re¬ 
mains  ignorant  as  to  the  location  of  the  problem,  it  is  likely  that  the  system 
cannot  be  controlled  by  management  procedures.  If  the  manager  or  controller 
is  kept  unaware  of  the  sources  of  the  various  demands  which  have  accumulated 
to  the  extent  that  they  are  causing  a  component  to  be  unduly  stressed,  he  will 
be  unable  to  choose,  except  by  chance,  the  control  procedure  most  appropriate 
for  dealing  with  that  situation.  Therefore,  the  status  of  the  system,  both 
as  a  whole  and  for  each  of  its  components,  must  be  monitored  continually  and 
provided  to  the  responsible  manager.  Proper  provisions  for  monitoring  the 
status  of  ABCC  system  components,  to  include  the  network  links  of  the  support¬ 
ing  communications  system,  must  be  included  in  the  ABCCS  hardware  and  soft¬ 
ware  designs.  That  monitoring  capability  is  the  interface  between  the  ABCCS 
proper  and  the  system  manager.  If  it  is  not  an  explicit  part  of  the  design, 
but  is  left  to  field  expedients,  the  most  clever  of  those  ad  hoc  methods  may 
still  be  inadequate  for  tracking  the  status  of  the  system.  The  extent  to 
which  the  management  interface  should  be  incorporated  into  the  system  design 
is  governed  by  two  major  considerations,  the  first  a  function  of  the  design 
of  the  system  upstream  from  the  interface  and  the  second  a  function  of  the 
downstream  problem: 

•  the  magnitude  of  the  system  control  tasks  which  are  left  for  the 
manager  to  perform;  and 

•  the  availability  of  status  information  in  the  detail  necessary  for 
effective  performance  of  those  system  control  tasks. 

1The  disciplined  field  of  decision  theory  contains  structured  methods  which 
can  be  applied  to  the  problem  of  guiding  a  manager  in  making  tradeoffs  be¬ 
tween  quantity  and  quality.  Situations  in  which  such  management  decisions 
are  required  are  characteristically  changing,  and  dealing  with  changing  situa¬ 
tions  satisfactorily  often  entails  making  continual  changes  in  the  value  sys¬ 
tems  on  which  decisions  are  made  for  managing  in  those  situations. 


It  seems  clear  that  these  two  considerations  are  likely  to  change  together; 
if  the  magnitude  of  the  management  task  becomes  large,  so  will  the  amount 
of  status  information  to  be  monitored,  and  vice-versa. 

The  purpose  of  the  work  being  reported  here  is  threefold.  It  is  to 
describe : 

•  how  hardware  and  software  design  parameters  of  the  kinds  of  ABCC 
systems  and  supporting  communications  under  contemporary  considera¬ 
tion  by  the  Army  can  affect  the  magnitude  of  the  remaining  system 
management  tasks; 

•  procedures  for  managing  the  system  burden;  and 

•  typical  monitoring  statistics  necessary  to  system  management  in 
field  operations. 

In  helping  to  fulfill  the  purpose  described  above,  it  is  helpful  to  use 
an  example  which  has  relevance  to  an  actual  ABCCS.  TOS,  as  it  might  have  been 
described  in  November  1979,  is  used  here  as  the  example  of  a  contemporary  ABCC 
system.  Extensions  from  that  particular  example  are  assumed  (for  example,  a 
freeze  in  a  component  design  in  such  a  manner  that  a  given  problem  becomes 
more  or  less  prominent)  when  useful  in  explaining  particular  management  pro¬ 
cedures  and  the  circumstances  for  their  possible  use. 

This  document  is  organized  into  three  chapters  in  addition  to  this  over¬ 
view.  Chapter  2.0  summarizes  an  analysis  of  the  example  TOS  and  its  support¬ 
ing  communications  design  parameters.  That  analysis  revealed  that  the  upper 
limit  on  the  utilization  of  any  component  is  characteristically  80  percent  of 
its  full  capability,  identifying  that  80  percent  utilization  level  as  the 
Rapacity  of  the  component  if  it  is  to  operate  within  acceptable  levels  of 
responsiveness.  The  analysis  determines  that  the  most  severe  management  prob¬ 
lem  that  could  be  expected  in  field  operations  is  overburden  of  FM  communica¬ 
tions  nets,  a  problem  which  is  serious  even  in  the  presence  of  fairly  modest 
bit  error  rates  and  exacerbated  when  retransmission  stations  are  used.  If  the 
FM  communications  problem  were  to  be  relieved,  the  next  two  component  over¬ 
burden  problems  in  order  of  severity  could  be  expected  on  the  multichannel 
communications  links  and  at  the  message  and  data  disk  controllers  of  the  main 
frame  computer.  The  software  design  was  not  sufficiently  mature  by  November 
1979  to  determine  the  memory  space  that  would  be  available  for  maintaining 
data  files  and  the  space  which  would  be  dedicated  to  buffering  the  front-end 
processor  (FEP)  or  the  remote  terminals.  In  consequence,  the  analysis  did 
not  extend  to  these  areas,  even  though  management  procedures  can  be  postu¬ 
lated  for  controlling  the  burdens  at  those  components. 

Chapter  3.0  describes  the  management  control  procedures  which  have  been 
identified  and  investigated  for  controlling  the  burden  of  demand  on  various 
system  components.  It  discusses  the  possible  causes  for  employing  each  of 
those  procedures,  individually  or  in  sets,  and  the  expected  narginal  effects 
on  the  system.  As  indicated  earlier,  it  also  discusses  some  cf  the  implica¬ 
tions  which  considerations  of  information  quality  might  have  or  selection  of 
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a  given  control  procedure.  Wherever  applicable  to  the  procedure  being  dis¬ 
cussed,  the  TOS  example  developed  in  chapter  2.0  is  used  as  a  case  in  point. 
Otherwise,  plausible  extensions  to  that  example  are  assumed  as  needed  to  help 
explain  a  management  procedure  in  the  context  of  a  specific  causal  agent. 

Chapter  4.0  discusses  the  need  for  the  system  manager/controller  to  be 
able  to  monitor  continually  the  status  of  the  system  as  a  whole  and  of  each 
of  its  components  in  order  to  identify  when  and  where  a  problem  is  develop¬ 
ing  or  already  exists  which  might  need  management  attention.  The  chapter 
also  summarizes  the  example  monitor  statistics  described  in  chapter  3.0  which 
could  be  expected  to  be  helpful  in  diagnosing  the  status  of  the  system  and 
in  determining  an  appropriate  management  action  to  resolve  an  operational 
problem.  The  reasons  why  those  statistics  must  be  made  available  by  design 
at  the  management  interface  of  the  system  with  its  users  and  must  not  be 
left  to  field  expedient  methods  have  been  covered  in  this  overview  discussion, 
but  also  become  evident  in  the  discussion  of  the  example  monitoring  statistics. 
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2.0  INFORMATION  FLOW  CONGESTION 


Initial  analysis  of  TOS,  the  example  ABCCS,  identified  the  likely  areas 
of  congestion  in  the  information  flow,  and  provided  the  basis  for  the  design 
of  management  procedures  to  detect  and  reduce  congestion  in  TOS.  The  analysis 
identified  traffic  flow  in  communications  systems  as  the  major  contributor  to 
congestion.  The  FM  nets  were  identified  as  the  primary  critical  components. 
The  Division  multichannel  net  and  the  disk  controllers  in  TOS  proper  were 
identified  as  secondary  critical  components.  These  components  will  operate 
effectively  provided  that  their  utilizations  do  not  exceed  80  percent.  The 
analysis  results  supporting  these  conclusions  are  summarized  in  the  remainder 
of  this  chapter. ^  The  software  design  was  not  sufficiently  mature  by  Novem¬ 
ber  1979  to  determine  the  memory  space  required  or  available  for  data  files 
and  front-end  processor  (FEP)  buffers.  In  consequence,  the  analysis  did  not 
extend  to  these  areas,  even  though  management  procedures  can  be  postulated 
for  controlling  the  burdens  at  those  components. 


2.1  ANALYSIS  PURPOSE  AND  APPROACH 

The  purpose  of  the  analysis  was  to  determine  the  operational  requirements 
of  TOS  and  to  evaluate  the  capability  of  the  proposed  system  to  meet  the  re¬ 
quirements.  The  analysis  approach  was  organized  into  a  series  of  objectives. 
Three  objectives  addressed  traffic  flow  congestion  in  the  example  TOS;  the 
others  addressed  design  issues.  The  results  summarized  in  this  chapter  relate 
to  the  first  three  objectives  and  pertain  to  the  example  TOS: 

(1)  identify  the  critical  system  components;  i.e.,  the  components  most 
likely  to  become  choke  points  and  cause  degradation  of  the  system; 

(2)  establish  operating  guidelines  which  would  prevent  choking  at  the 
critical  components;  and 

(3)  evaluate  the  impacts  of  the  field  conditions  on  the  performance  of 
the  primary  critical  components. 

The  primary  tool  used  in  the  analysis  was  a  mathematical  model  of  the 
steady  state  network  performance  based  on  a  representation  of  TOS  as  a  queue¬ 
ing  network.  The  network  components  are  the  FM  nets,  multichannel  net,  tacti¬ 
cal  computer  terminals  (TCTs),  tactical  computer  system  (TCSs),  and  the  disk 
controllers,  front-end  processor  and  data  base  processor  in  the  division  com¬ 
puting  center  (DCC).  The  model  used  a  set  of  inputs  describing:  (1)  network 
configuration;  (2)  the  engineering  characteristics;  (3)  the  operational  pro¬ 
cedures;  (4)  the  user  demand;  and  (5)  the  electromagnetic  environment.  The 
model  computed  three  outputs  for  each  component:  (1)  utilization — the  frac¬ 
tion  of  time  the  component  would  be  busy;  (2)  expected  queue  length — the 
average  number  of  messages  waiting  for  service;  and  (3)  expected  delay  for 
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The  analysis  is  documented  in  four  other  volumes  of  the  report  which  are 
identified  as  ARI  Research  Notes  80-12  through  80-15.  Full  titles  are  listed 
in  the  preface. 
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a  message — service  time  plus  waiting  time.  The  level  of  detail  of  the  model 
corresponded  to  the  detail  in  the  A-level  and  draft  B-level  system  specifica¬ 
tions.  Where  alternative  procedures  were  under  considerations,  alternative 
sub-models  were  prepared. 


2.2  CRITICAL  COMPONENTS 

A  five  stage  procedure  was  used  to  identify  the  critical  components: 

(1)  define  a  baseline  case; 

(2)  examine  the  sources  of  delay  in  the  baseline  case; 

(3)  examine  component  utilization  in  the  baseline  case; 

(4)  examine  the  ability  of  the  system  to  meet  the  user's  delay  require¬ 
ments  in  the  baseline  case;  and 

(5)  consider  impacts  of  further  degradation  from  adverse  field 
conditions . 

The  baselire  case  consisted  of  the  network  configuration  as  shown  in  exhibit 
2-1,  the  user's  projected  peak  hour  traffic  rates,  no  voice  competition  on  the 
nets,  no  f"  retransmission  stations,  and  a  realistic  range  of  error  rates  for 
transmission  be- ween  two  network  nodes  (0  to  10  bits  in  error  per  thousand 
bits  '.rans  \itted )  . 

rhe  chart  in  exhibit  2-2  shows  the  breakdown  of  the  expected  total  delay 
in  transmitting  and  processing  a  message  sent  from  a  battalion  in  contact  to 
the  Division  Computing  Center.  The  FM  net  accounts  for  almost  98  percent  of 
the  delay  at  zero  erro  rate,  and  the  percentage  is  larger  at  higher  error  rates 
The  delay  at  the  FM  net  consists  of  the  time  a  message  spends  waiting  to  get 
on  the  net,  and  the  transmission  time.  The  transmission  time  includes  over¬ 
head  to  establish  the  link  and  time  to  transmit  the  body  of  the  message.  As 
the  error  rate  increases,  the  probability  that  a  message  must  be  retransmitted 
due  to  errors  increases,  and  hence  the  transmission  time  increases.  As  the 
transmission  time  increases,  the  fraction  of  the  time  the  net  is  busy  increases 
and  consequently  the  waiting  time  increases. 

A  second  approach  to  identifying  the  critical  components  is  to  examine 
the  fraction  of  time  that  the  various  components  are  engaged.  A  chart  showing 
the  maximum  utilization  of  various  types  of  network  components  is  presented 
in  exhibit  2-3.  No  components  other  than  the  FM  nets  are  busy  more  than  10 
percent  of  the  time,  while  at  a  five  bits  per  thousand  error  rate  the  utiliza¬ 
tion  of  the  Cavalry  Squadron  FM  net  exceeds  80  percent. 
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System  Specifications  for  the  Division  Tactical  Operations  System  (DTPS), 
CO-SS-3000-TO,  April  1979,  and  Computer  Program  Item  Specification  Network 
Communications  Processing  for  Division  Tactical  Operations  System  (DTPS), 
CR-CS-0002-B12,  25  May  1979. 
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EXHIBIT  2-3:  COMPONENT  UTILIZATIONS 


COMPONENT  UTILIZATION 


The  user's  requirements  statement  referenced  in  the  system  specifications 
provided  a  range  of  maximum  tolerable  delays  taking  into  account  variations  in 
message  length,  network  configuration,  and  traffic  intensity.  As  shown  in 
exhibit  2-4,  the  average  delays  on  some  of  the  FM  nets  exceed  the  upper  limit 
of  the  tolerable  range  at  lower  error  rates  than  would  cause  the  average  multi¬ 
channel  delay  to  exceed  the  even  lower  limits. 

Based  on  the  foregoing  analysis,  the  FM  nets  were  identified  as  the  pri¬ 
mary  critical  components.  Furthermore,  the  performance  of  the  FM  nets  can  be 
severely  degraded  by  adverse  field  conditions.  For  example,  the  FM  nets  are 
to  be  shared  with  voice  transmission  and  hence  are  not  100  percent  available 
for  data  transmission .  In  addition,  retransmission  stations  are  used  to  ex¬ 
tend  the  range  of  some  FM  nets.  The  use  of  retransmission  stations  requires 
a  longer  overhead  time  to  establish  a  link,  and  the  multiple  transmissions 
produce  a  compounded  error  rate . 

The  multichannel  net  is,  like  the  FM  nets,  susceptible  to  transmission 
errors.  Due  to  the  higher  transmission  rate  (32  kbps  for  multichannel  vs. 

1.2  kbps  for  FM)  and  shorter  link-up  overhead  (0.1  seconds  for  multichannel 
vs.  1.5  seconds  for  FM  without  retransmission  stations),  the  multichannel 
net  is  able  to  operate  effectively  at  error  rates  much  higher  than  could  be 
tolerated  on  an  FM  channel.  The  multichannel  net  does  not  become  seriously 
congested  until  error  rates  in  excess  of  15  bits  per  thousand  are  reached. 

The  congestion  level  at  the  disk  controllers  depends  in  part  upon  the 
system  software.  The  software  design  was  not  sufficiently  mature  by  November 
1979  to  permit  definitive  analysis  of  the  congestion  at  the  disk  controllers. 
The  disk  controllers  are  slow  devices  and  unless  the  software  was  designed 
to  minimize  the  demand  on  the  controllers,  the  utilizations  could  easily  be 
as  high  as  the  8  percent  shown  in  exhibit  2-3.  This  potential  for  overload 
motivated  the  identification  of  the  disk  controllers,  along  with  the  multi¬ 
channel  nets,  as  secondary  critical  components. 


2.3  OPERATING  GUIDELINES 

The  provisional  TOS  standing  operating  procedures4  provide  for  system 
control  via  control  of  the  rate  of  user  access  to  the  system.  By  this  means 
the  System  Controller  can  control  the  traffic  rate  on  any  net.  The  FM  nets 
exhibit  a  characteristic  response  curve  relating  the  expected  delay  to  the 
traffic  rate  on  the  net.  An  example  of  this  response  curve  for  the  CAV  SQN 
FM  net  is  shown  in  exhibit  2-5.  The  response  curves  for  the  other  FM  nets 
differ  slightly  as  a  consequence  of  the  different  mix  of  messages  travelling 
over  each  net.  The  curves  do,  however,  have  some  important  characteristics 
in  common.  Expected  delay  responds  slowly  to  changes  in  the  traffic  rate 
when  the  net  is  operated  below  80  percent  utilization,  the  curves  exhibit  a 
knee  beyond  80  percent  utilization.  Traffic  rate  is,  therefore,  a  nearly 
linear  control  for  expected  delay  as  long  as  the  net  is  operated  below  80 
percent  utilization.  Similar  response  curves  define  the  relationship  between 


4See  ARI  Working  Paper  HF79-1. 
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expected  queue  length  and  traffic  rate.  The  operational  capacity  of  the  net 
may  be  defined  as  the  traffic  rate  which  produces  a  utilizaton  of  80  percent. 
A  sharp  guideline  for  avoiding  performance  degradation  due  to  congestion  on 
a  communication  net  is  to  keep  the  demand  within  the  operation  capacity. 


2.4  FIELD  CONDITIONS 


Various  field  conditions  affect  the  performance  of  the  FM  nets.  Fore¬ 
most  among  these  are  the  presence  of  transmission  errors  and  the  use  of  re¬ 
transmission  stations.  Exhibit  2-6  shows  the  effects  of  the  transmission  bit 
error  rate  on  the  capacity  of  the  CAV  SQN  FM  net  without  retransmission  sta¬ 
tions.  The  net  can  support  the  projected  peak  hour  load  up  to  an  error  rate 
of  approximately  5  bits  per  thousand. 

It  is  likely  that  a  cavalry  squadron  on  a  covering  force  or  flank  security 
operation  will  use  several  retransmission  stations  to  communicate  with  its 
division  headquarters.  Retransmission  stations  increase  the  link-up  overhead 
time  and  produce  a  compounded  error  rate.  Equipment  tests  and  theoretical 
computations  indicate  that  at  the  error  rates  under  consideration,  "n-1"  re¬ 
transmissions  produce  a  cumulative  error  rate  of  approximately  "n"  times  the 
error  rate  for  a  single  transmission.  Exhibit  2-7  presents  graphs  of  the 
CAV  SQN  FM  net  capacity  with  zero  and  three  retransmission  stations.  The 
x-axis  is  the  error  rate  for  a  single  transmission.  The  retransmission  sta¬ 
tions  severely  degrade  the  net's  capacity:  with  the  retransmission  stations 
the  net  cannot  support  the  required  traffic  at  error  rates  above  one  bit  per 
thousand.  Exhibit  2-8  presents  graphs  of  the  CAV  SQN  FM  net  capacity  when 
the  net  is  occupied  by  voice  0  and  25  percent  of  the  time,  and  demonstrates 
the  reduction  in  operational  capacity  as  a  result  of  voice  competition. 


2 . 5  SUMMARY 


It  is  clear  ;  om  this  analysis  of  TOS  that  the  information  flow  must  be 
carefully  managed  if  such  systems  are  to  be  kept  operationally  viable  in  the 
field.  Most  of  the  attention  of  the  System  Controller  will  be  directed  to 
controlling  the  traffic  flow  over  the  various  links  of  the  supporting  communi¬ 
cations  system,  and  attempting  to  ensure  that  the  quantity  and  quality  of 
information  which  flows  to  the  various  users  as  a  result  of  that  control 
process  continues  to  meet  the  tactical  information  needs  of  the  division. 

The  following  chapter  provides  a  set  of  procedural  recommendations  which,  if 
implemented,  will  supply  the  necessary  tools  to  allow  such  traffic  control. 
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EXHIBIT  2-8:  EFFECT  OF 
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3.0  PROCEDURES  FOR  MANAGING  A  TOS  SYSTEM  OVERLOAD 


At  the  termination  of  its  development,  the  Tactical  Operations  System 
(TOS)  was  being  designed  as  a  computerized  battlefield  information  system  to 
be  used  by  the  division  commander  and  his  staff  in  support  of  tactical  de¬ 
cisionmaking.  The  large  volume  of  information  available  to  such  a  system 
through  use  of  modern  data  collection  technology  poses  the  potential  of  hard¬ 
ware  and  software  overloads,  particularly  given  necessary  constraints  in  size 
due  to  considerations  such  as  need  for  mobility  and  low  vulnerability.  Coup¬ 
ling  this  potential  system  constraint  with  the  possibility  of  overloading  the 
human  users  of  the  system  with  an  inordinate  amount  of  information  which  they 
are  unable  to  assimilate  led  to  the  requirement  for  developing  procedures  for 
managing  the  use  of  TOS  and  its  data  base.  These  procedures  are  expected  to 
be  relevant  to  any  TOS-like  system  which  might  be  developed  to  support  tacti¬ 
cal  decisionmaking. 


3 . 1  INTRODUCTION 

Information  management  procedures  have  beer  developed  baseu  on  conqestion 
analysis  (summarized  in  the  preceding  chapter)  <t  what  might  happen  with  a 
fielded  TOS,  the  experience  with  FM-222  and  genera]  problems  that  occur  with 
computer  systems.  These  information  management  procedures  are  intended  to 
maximize  the  availability  of  information  from  the  system  and  to  prevent  or 
circumvent  identified  problems  of  system  overload,  storage  overload,  and  user 
overload.  The  procedures  include  methods  for  monitoring  and  controlling  the 
demands  on  the  system,  guidelines  for  performing  system  start-up  and  shut-down, 
and  definitions  for  some  of  the  data  fields  in  message  formats.  This  wide 
range  of  information  management  procedures  is  necessary  for  assuring  that  a 
high  level  of  timely  information  is  available  and  that  TOS  is  continuously 
able  to  support  the  progress  of  the  battle. 


3.1.1  SCOPE 

The  purpose  of  this  dociment  is  to  describe  how  management  procedures  can 
be  used  to  prevent  or  circumvent  problems  caused  by  excessive  demands  on  the 
TOS  system  components — computer,  communications,  and  user.  Of  the  management 
procedures  developed  in  phase  I  of  this  project,5  those  which  are  effective  in 
controlling  demand  are:  (1)  control  of  the  number  of  Incoming  Message  Re¬ 
trieval  requests;  (2)  operating  levels;  (3)  purging;  (4)  removal  of  user(s) 
from  distribution  list(s);6  and  (5)  hierarchical  review.  [In  addition  to 


5Blum,  et  al..  Information  Management  in  the  Tactical  Operations  System: 
Provisional  Standard  Operating  Procedures  (SOP),  VRI-ARI-3  FR79-1 ,  Vector 
Research,  Incorporated,  May  1979. 

6The  removal  of  user(s)  from  distribution  list(s)  was  not  explicitly  sug¬ 
gested  as  a  management  procedure  in  the  previous  phase,  but  has  since  been 
identified  as  likely  to  be  effective  in  addressing  information  problems. 
Misuse  of  the  distribution  list  may  cause  unnecessary  output  to  be  sent  to 
a  user,  resulting  in  a  possible  overload  of  a  user  and/or  a  communication 
link . 
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these  procedures,  the  management  procedures  developed  in  phase  I  covered  the 
topics  of  file  management,  user  guidelines,  and  information  processing  during 
degraded  modes  of  operation.  These  procedures  provide  the  system  user  with 
guidelines  for  interfacing  with  specific  features  of  the  TOS  system  and  are 
not  particularly  effective  in  controlling  demand.  For  example,  user  guide¬ 
lines  includes  guidelines  for  message  preparation  and  for  the  definition  of 
values  for  the  message  fields  which  have  no  prescribed  contents.  File  man¬ 
agement  addresses  the  unique  problems  of  each  file.]  Employment  of  one  or 
more  of  these  management  procedures  would  reduce  the  demands  placed  on  par¬ 
ticular  components  of  the  system.  The  choice  of  which  management  procedure(s) 
to  implement  requires  knowledge  of  the  strengths  and  side  effects  of  the 
procedures,  knowledge  of  the  cause  of  the  problem,  and  knowledge  of  the 
information  needs  of  each  TOS  user.  This  chapter  provides  information  about 
the  strengths  and  side  effects  of  each  of  the  five  procedures  mentioned  above, 
and  the  data  and  related  statistics  (parameters  which  describe  the  cause  of 
the  problem)  which  need  to  be  available  to  understand  if  a  particular  pro¬ 
cedure  would  be  effective  in  dealing  with  the  problem.  It  is  assumed  that 
the  person(s)  responsible  for  controlling  the  system  have  knowledge  of  the 
users'  information  needs  or  that  that  knowledge  can  be  easily  obtained.^ 

The  implementation  of  the  procedures  is  discussed  with  respect  to  repre¬ 
sentative  problems  of  system,  storage,  and  user  overloads.  This  discussion 
covers  a  method  for  choosing  the  management  procedure  or  procedures  to  imple¬ 
ment.  The  approach  is  through  examination  of  the  reduction  in  demand  which 
aan  be  realized  by  its  implementation,  and  its  possible  effect  on  the  quality 
of  information  processed  through  the  TOS  system.  The  purpose  is  to  explain 
how  the  person(s)  controlling  the  system  can  make  effective  management  deci¬ 
sions  in  maintaining  TOS  or  a  similar  command  and  control  system  in  an  opera¬ 
tionally  viable  condition. 


3.1.2  THE  RESPONSIBILITY  OF  MANAGEMENT 

The  system  controller  (SYSCON)  has  overall  responsibility  for  TOS  com¬ 
puter  center  installation  and  displacement,  TOS  system  configuration,  and 
maintenance  of  the  overall  effectiveness  of  TOS  computer  operations.  The 
SYSCON  coordinates  system  initialization  and  shut-down  activities  and  pre¬ 
pares  the  division  computer  center  for  relocation.  Members  of  the  system 
controller  element  monitor  and  control  the  data  base,  start  and  stop  the 
system,  monitor  system  status,  and  adjust  priorities  and  processing  schedules. 
The  SYSCON  is  responsible  for  contingency  procedures  in  the  event  of  software 
failure  and  monitors  the  quality  of  software  performance.  The  SYSCON  coor¬ 
dinates  the  communications  support  for  TOS  with  the  division  communications 
SYSCON. 


^Related  research  is  being  conducted  on  how  people  (commanders)  make  deci¬ 
sions  and  what  information  they  use  (information  requirements)  to  make  these 
decisions.  See  Methodologies  for  Determining  a  Decisionmaker's  Information 
Requirements ,  a  draft  working  paper  by  Greg  Touma,  Vector  Research,  Incor¬ 
porated,  14  March  1980. 


20 


The  function  of  the  SYSCON  as  the  overall  manager  of  information  process¬ 
ing  in  TOS  is  to  coordinate  the  technical  capabilities  of  TOS  and  the  opera¬ 
tional  needs  of  its  users.  The  restrictions  imposed  by  the  capacity  of  the 
data  base  storage  devices  and  the  processing  times  needed  for  transactions 
may  require  that  limits  be  placed  on  the  demands  made  on  the  system.  The 
SYSCON  is  responsible  for  coordinating  these  demands  with  the  capabilities 
of  TOS.  This  requires  that  the  SYSCON  monitor  each  component  of  the  system 
in  order  to  diagnose  the  existence  of  a  problem  and  understand  the  cause  of 
the  problem.  In  response  to  a  given  problem  he  may  advise  the  file  managers 
as  to  when  they  must  act  to  reduce  the  size  of  their  files,  or  instruct  TOS 
users  as  to  their  permitted  access  to  the  system,  or  take  action  himself 
which  will  rectify  the  problem. 

The  SYSCON  has  the  responsibility  for  managing  the  use  of  the  TOS  system 
and  may  task  the  file  managers  and  TOS  users  to  implement  the  management  de¬ 
cisions.  The  extent  to  which  the  file  managers  and  users  are  involved  in  the 
management  of  TOS  would  be  a  matter  of  local  option  and  the  specific  problems 
which  occur.  The  file  manager's  responsibility  is  to  ensure  that  the  contents 
of  the  file(s)  delegated  to  him,  however  constrained  in  size  or  other  techni¬ 
cal  characteristics,  can  provide  maximum  information  value  to  the  file  users. 
The  file  manager  coordinates  with  the  SYSCON  prior  to  taking  any  file  action 
that  might  reduce  system  effectiveness,  and  warns  the  SYSCON  of  major  antici¬ 
pated  changes  in  the  space  or  processing  requirements  of  the  files.  The  users 
are  instructed  by  the  SYSCON  on  the  access  which  they  are  permitted  to  the 
system.  When  problems  arise  which  require  that  demands  be  decreased  by  one 
or  more  users,  the  affected  user(s)  may  be  involved  in  deciding  how  the  re¬ 
duction  in  demand  is  achieved  (the  choice  among  the  management  procedures), 
he  (they)  may  be  instructed  as  to  which  action  to  take,  or  the  corrective  ac¬ 
tion  may  be  taken  without  any  user  involvement.  Depending  on  the  level  of 
involvement  users  have  in  the  management  of  TOS  they  may  need  to  have  knowl¬ 
edge  of  the  status  of  TOS,  particularly  of  the  components  which  their  demands 
impact,  and  the  effects  of  each  of  the  management  procedures  on  both  the  quan¬ 
tity  and  quality  of  information.  Involving  the  TOS  users  in  the  management 
of  TOS  would  likely  resu)f  in  the  users  being  more  satisfied  with  the  system, 
as  they  have  the  best  knowledge  of  their  information  needs  and  how  they  use 
TOS  to  satisfy  these  needs.  Another  advantage  of  involving  the  user  in  the 
management  of  the  system  is  that  the  burden  on  the  SYSCON  to  perform  this 
task  should  be  decreased,  particularly  in  the  amount  of  monitoring  which  is 
necessary  to  make  effective  and  acceptable  management  decisions. 

In  the  discussion  of  the  management  procedures  which  follows,  the  SYSCON 
is  assumed  to  be  totally  responsible  for  the  management  of  TOS.  This  keeps 
the  discussion  of  the  task  of  management  centralized  and  should  make  it  easier 
to  understand  the  complete  process  of  management.  It  also  draws  attention  to 
the  fact  that  effective  management  of  TOS  is  complex  and  requires  extensive 
knowledge  of  the  system,  the  battlefield  situation,  and  the  information  needs 
of  TOS  users. 


3.2  THE  MANAGEMENT  PROCEDURES 


The  purpose  of  this  section  is  to  discuss  the  five  management  procedures 
which  have  been  identified  as  effective  in  addressing  problems  of  overloads 
of  TOS  system  components.  For  each  procedure  the  topics  covered  are  the 
purpose  of  the  procedure,  the  procedure  itself,  the  effect  of  employing  the 
management  procedure  on  the  quantity  and  quality  of  messages  processed  by  the 
system,  and  finally  the  information  which  needs  to  be  available  to  employ  the 
procedure.  The  effect  of  the  procedure  on  quantity  is  measured  as  the  amount 
of  decrease  in  utilization  (of  the  overloaded  component)  which  can  be  expected 
given  the  procedure  is  implemented  at  some  level.8  Utilization  of  a  computer 
processor  (message  disk  controller  and  data  disk  controller)  is  calculated 
as  the  ratio  of  the  amount  of  time  required  by  the  processor  to  perform  the 
tasks  demanded  in  a  given  time  interval  to  the  length  of  the  time  interval. 
Utilization  of  a  communications  link  is  defined  as  the  ratio  of  the  total 
length  (in  characters)  of  all  messages  transmitted  over  the  link  in  a  spe¬ 
cific  time  interval  to  the  maximum  number  of  characters  that  link  can  trans- 

Q 

mit  in  that  period  of  time.  The  utilization  of  a  user  can  be  measured  by 
a  weighted  combination  of  the  total  number  of  messages  he  composes  and  the 
total  number  of  messages  he  receives  in  a  given  period  of  time,  divided  by 
the  number  it  has  been  determined  he  can  effectively  assimilate  in  a  period 
of  time.^0  The  discussion  of  the  impacts  of  the  management  procedure  on 
quality  considers  the  effects  of  employing  the  procedure  on  the  quality  of 
messages  sent  or  received  by  the  users  directly  affected  by  the  action  and 
the  quality  of  messages  received  by  other  users  for  whom  the  procedure  did 
not  directly  impact.  These  quality  effects  are  examined  in  terms  of  changes 
in  the  distribution  of  message  types  (SRI  response,  update  messages,  etc.) 
processed  throughout  the  system.  The  information  necessary  to  employ  the 
management  procedure  are  the  statistics  which  need  to  be  available  to  the 
SYSCON  in  order  to  choose  the  procedure  or  set  of  procedures  which  are  most 
effective  in  correcting  the  overload. 


8 

In  steady  state  analysis,  utilization  is  defined  as  the  fraction  of  time 
which  the  component  is  busy. 

g 

The  effect  of  transmission  error  is  included  in  the  number  of  messages 
transmitted  over  a  given  period  of  time.  If  a  message  is  transmitted  and 
received  incorrectly,  it  will  have  to  be  transmitted  again  or  deleted,  ef¬ 
fectively  increasing  the  number  of  messages  transmitted. 

10The  emphasis  of  this  analysis  was  primarily  on  the  system  and  storage  over¬ 
load  problem.  The  user  overload  problem  was  addressed  by  empirical  exami¬ 
nation  of  the  amount  of  messages  each  user  composes  and  receives  and  the 
capacity  humans  have  to  assimilate  information.  This  type  of  measure  of  the 
utilization  of  users  appears  to  be  reasonable  for  quantifying  the  overload 
problem,  but  the  numerical  values  which  are  appropriate,  as  well  as  the 
appropriateness  of  this  type  of  function,  needs  to  be  determined  by  further 
research,  possibly  through  field  experiments.  Further  discussion  of  the 
user  overload  problem  is  given  in  subsection  3.3.4. 
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3.2.1  PROCEDURE  I:  CONTROL  OF  THE  NUMBER  OF  INCOMING  MESSAGE 
RETRIEVAL  REQUESTS 

The  Incoming  Message  Retrieval  ( IMR)  requests  include  all  the  information 
processes  which  screen  messages  incoming  to  the  DCC;  specifically,  SRIs  (Stand¬ 
ing  Requests  for  Information),  thresholds,  correlations,  and  filters.  As  each 
message  arrives  at  the  DCC,  message  retrieval  criteria  are  examined  to  deter¬ 
mine  if  the  message  satisfies  any  set  of  criteria  a  user  has  specified.  If 
the  message  does  not  satisfy  any  of  the  criteria,  the  message  is  retained  in 
the  system  and  no  further  processing  occurs.^  If  the  criteria  are  satisfied, 
one  of  the  following  four  actions  will  occur: 

(1)  If  the  screening  criteria  are  for  an  SRI,  a  copy  of  the  message  is 
sent  to  the  originator  of  the  SRI  and  other  users  specified  on  the 
distribution  of  the  SRI. 

(2)  If  the  criteria  are  associated  with  a  threshold,  a  search  of  the 
data  base  is  triggered  and  records  matching  the  threshold  query  are 
located.  If  the  search  is  successful  (the  threshold  specified  is 
met)  the  originator  is  notified  of  the  successful  search  and  the 
incoming  message  which  triggered  the  search.  If  the  threshold  is 
not  met,  no  output  is  generated. 

(3)  If  the  criteria  are  associated  with  a  correlation,  a  search  of  the 
data  base  is  triggered  via  a  query  (a  maximum  of  two  Queries  may 
be  initiated) .  The  results  of  the  query  and  the  incoming  message 
are  sent  to  the  originator;  or 

(4)  If  the  screening  criteria  are  associated  with  a  filter,  one  of  the 
following  four  things  may  occur:  the  incoming  message  is  deleted; 
the  incoming  message  is  sent  to  the  originator  of  the  filter  for 
review;  a  duplication  query  is  initiated  and  if  successful  (a  dupli¬ 
cate  message  found  in  the  data  base),  the  incoming  message  is  deleted; 
or  a  duplication  query  is  initiated  and  if  successful,  the  message 

is  sent  to  the  originator  of  the  filter  for  review.  The  result  of 
review  is  either  deletion  or  acceptance  of  the  incoming  message. 

These  functions  provide  a  convenient  way  for  TOS  users  to  obtain  their  infor¬ 
mation  requirements,  but  without  careful  construction  of  these  requests  and 
controls  on  the  number  and  type  of  recruests  TOS  users  develop,  some  of  the 
system  components  may  be  underlying  burdened  and  vulnerable  to  overload. 

Overloads  of  the  computer  processors  may  occur,  particularly  the  message 
disk  controller  and  the  data  disk  controller,  if  the  number  of  criteria  which 
need  to  be  examined  are  excessive,  if  the  number  of  searches  of  the  data  base 
(due  to  the  correlations,  thresholds,  and  filters)  are  inordinate,  or  if  the 


^If  the  incoming  message  contains  entries  in  the  distribution  field,  the 
message  is  distributed  to  those  users. 
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data  base  is  too  large  and  too  many  records  must  be  checked.  Overloads  of 
the  communications  links  may  occur  if  the  output  load  propagated  by  these  re¬ 
quests  is  more  than  the  communications  net  can  support.  Since  the  output 
from  these  requests  is  not  directly  controllable,  as  they  are  initiated  auto¬ 
matically  by  TOS  in  response  to  incoming  IMR  messages  from  all  sources,  it  is 
possible  that  unforeseeable  changes  in  the  input  message  stream  may  result  in 
an  increase  in  the  amount  of  output  generated  and  an  overload  of  one  or  more 
communications  links.  This  result  may  or  may  not  be  desirable  to  the  involved 
user,  and  this  phenomenon  may  also  result  in  an  overload  of  the.  user(s).  A 
user  overload  may  also  occur  if  too  many  or  too  broad-range  requests  (an  at¬ 
tempt  to  "cover  all  bases")  are  developed  or  if  care  is  not  taken  in  defining 
to  whom  the  output  is  sent  (unreasonable  use  of  the  distribution  lists),  re¬ 
sulting  in  unwanted  information  being  sent  to  users.  The  procedure  proposed 
here  addresses  the  circumvention  of  these  problems  by  controlling  the  number 
of  these  requests  and  reducing  the  number  as  needed  in  response  to  an  increase 
in  utilization  of  a  system  component. 

Controlling  the  number  of  requests  that  users  establish  not  only  pro¬ 
motes  satisfactory  system  operation,  but  also  motivates  users  to  eliminate 
requests  which  are  outdated  and  to  consider  the  usefulness  of  a  request  be¬ 
fore  adding  it  to  the  system.  The  number  of  each  type  of  the  IMR  requests 
an  individual  user  is  permitted  to  have  in  the  system  is  based  on  considera¬ 
tion  of  the  total  number  which  the  computer  system  can  process  and  the  rela¬ 
tive  information  needs  of  the  user.^  The  SYSCON  will  be  required  to  reduce 
(or  possibly  increase)  the  permitted  number  of  requests  in  the  system  in 
response  to  changes  in  user  requirements  due  to  changes  in  mission  or  in 
response  to  a  degradation  of  the  system  resulting  in  increased  utilization 
of  a  particular  component.  [In  this  document  emphasis  is  placed  on  how  man¬ 
agement  procedures  can  be  used  to  rectify  problems  of  overload;  therefore, 
the  implementation  of  the  procedure  is  discussed  from  the  aspect  of  reducing 


12 

The  demand  that  is  placed  on  the  computer  processors  by  the  examination  of 
the  message  retrieval  criteria  and  the  searches  of  the  data  base  are  dependent 
on  the  design  of  the  software  and  hardware  of  the  computer  system.  At  this 
time,  the  occurrence  of  overloads  of  these  processors  by  IMR  reauests  is 
hypothesized . 

13The  increase  in  utilization  may  be  due  to  factors  such  as  those  described 
which  affect  the  demands  placed  on  the  components  or  because  of  environmental 
changes  which  affect  the  total  "usable"  capacity  of  the  compnent.  For  exam¬ 
ple,  the  effect  of  environmental  conditions  on  communications  nets  (see  sub¬ 
section  2.4). 

14 

An  examination  of  the  demands  placed  on  the  system  by  projected  peak  hour 
message  loads  and  the  user  requirement  for  the  use  of  these  IMR  requests  has 
shown  that  these  requirements  are  satisfactorily  met  by  the  system  as  it 
was  defined  when  work  halted  in  November  1979.  See  Witus  et  al . ,  Analysis 
of  Information  Flow  in  the  Tactical  Operations  System,  ARI*  Research  Note 
80-12. 
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the  number  of  IMR  requests  in  response  to  an  identified  overload,  it  should 
be  relatively  straightforward  to  see  how  this  procedure  could  be  used  to  in¬ 
crease  the  number  of  requests  in  the  event  that  the  state  of  the  system  allows 
increased  use  of  the  system.] 

Once  an  overload  problem  is  identified,  a  decision  is  required  as  to 
which  type  of  IMR  requests  are  to  be  deleted  and  in  what  numbers  in  order  to 
obtain  the  desired  effect  on  the  utilization  of  the  overloaded  component.  A 
reduction  in  any  four  of  the  IMR  requests  affects  the  user(s)  to  whom  the  re¬ 
sponses  are  sent,  the  communications  link(s)  over  which  the  responses  travel, 
and  the  computer  processors  which  handle  the  requests.  The  magnitude  of  the 
impacts  on  each  of  these  components  is  dependent  on  the  type  of  IMR  requests, 
and  therefore  are  discussed  individually  in  the  paragraphs  below.15  Included 
in  this  discussion  of  each  type  of  request  is  the  impact  of  a  reduction  in 
the  number  of  requests  on  the  quality  of  information  processed  by  the  system. 
The  combination  of  the  effects  of  implementing  the  procedure  on  quantity  and 
quality  provide  the  SYSCON  with  a  basis  on  which  to  make  a  decision  as  to 
whether  or  not  to  implement  the  procedure.  The  decisionmaking  process  is 
discussed  with  respect  to  specific  system  overload  problems  in  section  3.3 
following  a  discussion  of  the  four  remaining  management  procedures. 


Standing  Request  for  Information  (SRI) 

The  magnitude  of  the  effect  of  a  reduction  in  the  number  of  SRI  on  a  user 
is  simply  the  number  of  response  messages  which  the  user  will  no  longer  re¬ 
ceive  from  the  SRI  which  are  deleted.  The  decrease  in  the  utilization  of  the 
communication  nets  over  which  the  SRI  responses  travel  is  a  combination  of 
the  number  of  responses  which  are  deleted,  the  length  of  the  response  in 
characters,  and  the  number  of  times  the  response  would  have  to  be  transmitted 
in  order  to  be  received  correctly  (the  effect  of  errors  in  transmission).  The 
decrease  in  utilization  of  the  message  disk  controller  is  determined  by  the 
number  of  SRI  which  would  be  matched  by  an  incoming  message  and  the  number  of 
users  to  whom  the  response  would  be  sent.  Finally,  the  effect  on  the  data 
disk  controller  is  the  number  of  times  the  SRI  which  are  deleted  would  have 
been  checked  against  incoming  messages  which  in  turn  is  dependent  on  the 
characteristics  of  the  input  stream.  For  a  system  based  on  estimates  pro¬ 
vided  by  the  system  A-  and  B-level  specifications,  the  effect  of  decreasing 
the  number  of  SRI  by  50  percent  on  five  of  the  system  components  is  given 
in  exhibit  3-1. 

The  effects  on  the  quality  of  information  from  SRI  are  determined  by  the 
value  of  the  SRI  responses  to  the  users.  If  the  responses  are  distributed 
to  more  than  the  originator  of  the  SRI,  the  value  of  the  response  to  these 
users  must  be  considered  also.  Other  impacts  which  are  equally  difficult  to 
quantify  are  the  degree  to  which  users  may  employ  other  information  processes; 


15The  magnitude  of  the  impact  is  also  deperd°nt  on  the  software  design  and 
performance  capability  of  each  component.  In  the  discussion  which  follows, 
the  impact  is  based  on  analysis  of  the  TOS  system  as  it  was  defined  and 
documented  in  November  1979. 


25 


EXHIBIT  3-1:  EFFECT  OF  A  DECREASE  IN  SRI  ON  TOS  COMPONENTS 
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for  example,  queries  to  obtain  the  information  they  no  longer  receive  from 
these  SRI,  and  the  magnitude  of  the  resulting  increases  on  utilizations  of 
the  TOS  system  components. 


Thresholds 


The  threshold  function  is  used  primarily  by  intelligence  analysts  for 
automated  message  processing.  The  use  of  the  function  is  not  much  of  a 
burden  to  the  system  users  as  the  output  is  expected  to  be  short  and  infre¬ 
quent.  The  magnitude  cf  a  decrease  in  number  of  thresholds  on  utilization 
of  a  communications  link  is  similarly  small  as  seen  in  exhibit  3-2.  The 
factors  which  determine  the  magnitude  are  the  number  of  responses  which  are 
eliminated  as  a  result  of  the  deleted  threshold  requests  and  the  length  of 
the  response.  The  effect  on  the  message  disk  controller  is  also  not  sub¬ 
stantial  as  factors  which  determine  the  impact  are  the  number  of  responses 
generated  by  the  threshold  and  the  number  of  people  to  whom  the  output  is 
distributed;  which  is  likely  to  be  only  the  originator  of  the  threshold. 

The  greatest  impact  of  a  reduction  in  the  number  thresholds  is  on  the 
data  disk  controller  which  handles  all  the  accesses  to  the  data  base  to 
determine  if  the  threshold  query  is  triggered  and  then  determines  if  the 
threshold  is  met.  The  factors  involved  in  estimating  the  magnitude  of  reduc¬ 
tion  in  utilization  of  the  data  disk  controller  are  the  number  of  threshold 
requests  which  are  deleted,  the  frequency  with  which  they  are  triggered,  and, 
for  those  triggered,  the  number  of  keys  and  key  values  specified  by  the 
threshold  query. 

The  quality  considerations  involved  in  deleting  some  threshold  requests 
include  not  only  the  value  intelligence  analysts  place  on  the  information 
received  from  these  requests,  but  also  the  impact  on  the  products  of  their 
analyses.  The  threshold  function  provides  a  means  by  which  analysts  can 
process  data  records  into  information  and  intelligence  which  is  more  com¬ 
plete,  accurate,  and  meaningful.  This  can  improve  the  general  quality  of 
information  processed  by  the  system  and  may  also  decrease  the  size  of  the 
data  base,  eliminating  redundant  data  records  and  combining  others. 


Correlations 


Like  the  threshold  requests,  correlations  are  also  primarily  used  by 
intelligence  analysts  for  automated  processing  of  data.  The  output  to  these 
users  from  a  correlation  are  data  records  or  some  type  of  computer- generated 
report  which  provides  the  results  from  the  automated  query  (queries)  triggered 
by  the  correlation  and  the  incoming  message.  This  output  may  be  quite  lengthy 
and  difficult  for  a  user  to  assimilate,  especially  if  not  in  a  report  format; 
therefore,  users  should  be  careful  as  to  the  construction  of  these  correla¬ 
tion  requests.  The  effect  of  reducing  the  number  of  correlation  requests  on 
a  user  is  simply  the  elimination  in  the  messages  they  would  have  generated. 

The  factors  which  affect  the  magnitude  of  the  decrease  in  utilization  of  the 
communications  link  over  which  the  responsa  travels  are  the  frequency  that 
the  correlations  which  are  to  be  deleted  would  have  been  triggered,  the  length 
of  the  output  in  characters  generated  by  these  correlations,  and  the  number 
of  times  the  output  would  have  to  be  transmitted  in  order  to  be  received 
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EXHIBIT  3-2:  EFFECT  OF  A  DECREASE  IN  THRESHOLD  QUERIES  ON  TOS  COMPONENTS 


Nouvzniin 


TOS  COMPONENTS 


correctly  by  the  receiving  node  (effect  of  transmission  errors).  As  with 
thresholds,  the  magnitude  of  the  effect  on  the  message  disk  controller  of 
a  decrease  in  the  number  of  correlations  is  expected  to  be  small  because 
the  number  of  times  a  correlation  is  triggered  is  expected  to  be  infrequent 
and  the  distribution  of  the  output  is  likely  limited  only  to  the  originator 
of  the  correlation  request.  The  greatest  impact  of  a  decrease  in  the  number 
of  correlations  is  expected  to  be  seen  on  the  data  disk  controller.  The  fac¬ 
tors  which  determine  the  magnitude  of  this  decrease  are  the  number  of  corre¬ 
lations  which  are  deleted,  the  frequency  with  which  the  message  retrieval 
criteria  associated  with  these  correlations  would  be  tested,  the  frequency 
with  which  the  query  (queries)  associated  with  these  correlations  would  be 
triggered,  and  the  number  of  keys  and  key  values  specified  in  the  query 
(queries ) . 

The  impact  of  a  reduction  in  the  number  of  correlations  on  the  quality 
of  information  processed  by  the  system  is  expected  to  be  like  that  described 
for  thresholds.  Briefly,  the  considerations  are  the  value  of  these  responses 
to  the  users  and  the  impacts  which  may  be  seen  in  the  quality  and  quantity  of 
information  stored  in  the  data  base. 


Filters 


The  filter  requests  are  originated  by  file  managers  to  control  the  quan¬ 
tity  and  quality  of  information  added  to  their  file(s).  This  function  gives 
the  file  managers  the  ability  to  check  messages  for  accuracy,  completeness, 
and  redundancy.  The  magnitude  of  the  effect  on  the  user  of  a  decrease  in 
utilization  of  filters  is  determined  by  the  frequency  with  which  the  deleted 
filters  generate  output.  A  reduction  occurs  both  in  the  input  from  and  out¬ 
put  to  the  user  because  action  is  required  by  the  user  either  to  approve  or 
delete  any  message  screened  by  the  filter.  A  reduction  in  the  utilization 
of  communication  links  over  which  the  responses  travel  is  determined  by  the 
frequency  with  which  the  filter  generates  output,  the  length  of  the  output, 
the  length  of  the  response  generated  by  the  user  to  the  filter  output,  and 
the  number  of  times  the  filter  response  and  the  user  response  would  have  to  be 
transmitted  in  order  to  be  received  correctly  at  the  intended  receiver  node. 
Since  the  filter  responses  are  expected  to  be  short  in  length,  relatively  in¬ 
frequent,  ar 1  distributed  only  to  the  originator  of  the  filter,  any  reduction 
in  the  number  of  filters  results  in  a  relatively  small  decrease  in  the  utili¬ 
zation  of  the  user  and  the  communication  nets.  Similarly,  a  small  decrease 
in  the  utilization  of  the  message  disk  controller  is  expected  as  a  result  of 
a  decrease  in  the  number  of  filters,  as  the  factors  which  determine  the  mag¬ 
nitude  of  the  effect  are  the  frequency  with  which  output  would  be  generated 
by  these  filters  and  the  number  of  users  to  whom  the  output  would  be  distrib¬ 
uted.  The  magnitude  of  the  effect  of  a  decrease  on  the  utilization  of  the 
data  disk  controller  is  rather  complex  as  the  function  permits  the  user  many 
alternative  actions.  The  factors  which  must  be  considered  in  determining 
the  magnitude  are:  the  number  of  filters  to  be  deleted  and  the  frequency 
with  which  the  associated  message  retrieval  criteria  would  be  tested;  the 
frequency  with  which  these  criteria  would  be  satisfied  so  that  a  data  base 
search  is  required;  and  the  number  of  keys  and  key  values  associated  with 
that  search.  A  significant  decrease  in  utilization  of  the  data  disk  con¬ 
troller  may  be  obtained  by  a  decrease  in  the  number  of  filters. 
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A  reduction  in  the  number  of  filters  would  primarily  decrease  the  quality 

and  increase  the  quantity  of  data  stored  in  the  data  base.  These  c'.  anges  may 

require  an  increase  in  the  amount  of  purging  needed  to  maintain  the  data  base 
and  decrease  TOS  user  satisfaction  when  he  queries  the  data  base.  In  addition, 
the  filters  decrease  the  number  of  input  messages  distributed  to  users  and 
reduction  of  the  filters  would  likely  increase  the  load  on  the  users,  system, 
and  communications  links.  Consideration  should  be  given  to  this  factor  when 
selecting  the  filter  to  delete. 

In  response  to  an  identified  overload  at  a  particular  component,  the 

SYSCON  might  choose  to  reduce  the  number  of  IMR  requests  in  the  system.  The 

decision  as  to  which  type  or  types  and  the  amount  would  depend  on  the  quantity 
and  quality  factors  described  above  and  the  number  of  each  of  these  in  the 
system  at  the  time.  The  statistics  which  need  to  be  available  to  the  SYSCON 
in  order  to  assess  the  impacts  on  quantity  and  those  associated  with  factors 
described  above  are  given  in  exhibit  3-3.  ^  The  SYSCON  is  assumed  to  have 
knowledge  of  the  battlefield  situation  and  users'  information  needs.  Given 
the  component  which  is  overloaded  and  the  characteristic  of  the  overload,  the 
SYSCON  can  use  these  statistics  to  determine  the  reduction  in  a  particular 
type  IMR  request  that  is  required  in  order  to  rectify  a  problem  and  whether 
or  not  that  reduction  would  be  acceptable  to  the  TOS  users. 


3.2.2  PROCEDURE  II:  OPERATING  LEVELS 

The  concept  of  operating  levels  has  been  developed  to  provide  a  means  to 
coordinate  user  demands  (data  base  updates  and  queries)  with  the  operating 
status  of  TOS.  They  are  tools  by  which  the  SYSCON  can  guide  TOS  users  to 
respond  to  changes  in  the  status  of  TOS  due,  for  example  to  a  communications 
net  overload.  Operating  levels  are  a  pre-defined  set  of  constraint  values 
on  the  number  of  update  and  query  messages  a  user  can  place  in  the  system. 

For  example,  using  a  4-level  system,  a  TOS  user  may  be  given  the  following 
set  of  parameters  for  each  level: 

Level  No.  Queries  per  Hour  No.  Updates  per  Hour 


A 

20 

30 

B 

10 

20 

C 

5 

10 

D 

0 

0 

16 

These  statistics  are  assumed  to  be  available  to  the  SYSCON  either  auto¬ 
matically,  by  querying  the  data  base  for  the  component  data,  or  by  survey¬ 
ing  users  and  file  managers  for  the  appropriate  informatiqn  and  performing 
the  necessary  calculations. 
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EXHIBIT  3-3:  MONITOR  STATISTICS  FOR  INFORMATION  RETRIEVAL  REQUESTS 


SRI 

THRESHOLD 

CORRELATION 

FILTER 

Number  of  SRI  in 
system,  by 
originator. 

Number  of  thres¬ 
holds  in  system, 
by  originator. 

Number  of  Correla¬ 
tions  in  system, 
by  originator. 

Number  of  filters 
in  system,  by 
originator. 

Frequency  that 

IMR  criteria  for 
SRI  are  checked 
(characteristics 
of  input  arrival 
stream)'. 

Frequency  that 

IMR  criteria  for 
thresholds  are 
checked  (charac¬ 
teristics  of  input 
arrival  stream). 

Frequency  that 

IMR  criteria  for 
correlations  are 
checked  (charac¬ 
teristics  of  input 
arrival  stream). 

Frequency  that 

IMR  criteria  for 
filters  are  check¬ 
ed  (characteris¬ 
tics  of  input 
arrival  stream). 

Frequency  that 

IMR  criteria  for 
SRI  are  satisfied. 

Frequency  that 

IMR  criteria  for 
thresholds  are 
satisfied. 

Frequency  that 

IMR  criteria  for 
correlations  are 
satisfied. 

Frequency  that 

IMR  criteria  for 
filters  are 
satisfied. 

Frequency  that 
threshold  criteria 
are  satisfied. 

Average  number  of 
queries  triggered. 

Frequency  that 
a  data  base  search 
is  triggered. 

1 

1 

! 

Frequency  that  a 
response  is  sent 
(with  or  without 
a  data  base 
search) . 

j 

i 

t 

1 

i 

i 

I 

Average  number  of 
keys  and  key 
values  searched. 

Average  number  of 
keys  and  key 
values  searched. 

Average  number  of  j 
keys  and  key  ! 
values  searched,  | 
if  data  base  j 
search  is  required. 

Distribution  of 

SRI  responses. 

Distribution  of 

threshold 

responses. 

Distribution  of 

correlation 

responses. 

Distribution  of 
filter  responses. 

These  statistics  can  be  monitored  for  the  system  as  a  whole,  then  extended 
to  apply  for  each  individual  request  to  estimate  the  effect  of  each 
management  procedure  on  utilization. 
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At  level  A,  the  TOS  user  would  be  permitted  to  transmit  20  queries  per  hour 
and  30  updates  per  hour;  whereas,  at  level  C  he  would  be  restrained  to  trans¬ 
mit  at  or  below  a  rate  of  5  and  10  per  hour,  respectively.  In  general,  the 
level  of  operation  may  be  associated  with  a  level  of  system  operability  in  the 
sense  that  at  level  A  the  system  would  be  operating  satisfactorily;  hence, 
the  level  defines  the  maximum  allowable  rate  of  demand  by  a  user.  Similarly, 
at  level  D  operation,  no  TOS  interaction  would  be  permitted  if,  for  example, 
the  Division  Computer  Center  (DCC)  had  crashed.  Levels  B  and  C  define  inter¬ 
mediate  levels  of  use.  In  response  to  an  identified  overload  the  SYSCON  may 
choose  to  decrease  the  utilization  of  the  component  by  lowering  the  operating 
level  of  one  or  more  users.  The  magnitude  of  the  effect  on  the  user  is  the 
difference  in  number  of  update  and  query  messages  between  the  current  level 
of  operation  and  the  lower  level.  In  addition,  a  decrease  would  also  be  seen 
in  the  amount  of  output  that  user  receives  due  to  the  reduction  in  the  number 
of  queries.  The  magnitude  of  the  decrease  in  utilization  of  the  communication 
net  over  which  the  user's  inputs  travel  would  depend  on  the  decrease  in  the 
number  of  inputs  (updates  and  queries)  and  the  length  of  these  inputs,  the 
number  of  queries  and  the  length  of  the  responses  to  these  queries,  and  the 
number  of  times  which  these  messages  would  have  to  be  transmitted  over  the 
communications  link  in  order  to  be  received  correctly  at  the  receiver  node. 

The  effect  of  a  decrease  in  operating  level  on  the  message  disk  driver  is 
dependent  on  the  reduction  in  the  number  of  updates  and  queries,  and  the  dis¬ 
tribution  of  output  associated  with  these  demands.  The  effect  on  the  data 
disk  controller  depends  on  the  reduction  in  number  of  updates  and  the  number 
of  keys  in  the  inverted  key  buffer  which  must  be  updated,  and  the  reduction 
in  the  number  of  queries  and  the  number  of  keys  and  key  values  which  must  be 
searched  to  satisfy  the  query.  Indirect  effects  on  the  utilization  of  other 
users,  the  communication  links,  and  the  message  disk  and  data  disk  controllers 
can  be  expected  because  of  changes  in  the  message  stream  which  the  IMR  re¬ 
quests  act  upon. 

Two  basic  considerations  with  respect  to  quality  need  to  be  addressed 
before  a  decision  is  made  to  decrease  the  operating  level  of  user(s).  First 
is  the  value  of  the  update — add  and  change — messages  submitted  by  the  user(s) 
to  the  rest  of  the  division.  Secondly,  the  value  of  the  prohibited  queries 
to  the  user(s)  whose  operating  level  is  decreased  needs  to  be  considered. 

The  SYSCON' s  decision  to  decrease  the  operating  level  of  a  user  would 
reflect  the  value  of  the  decrease  in  the  utilization  of  the  overloaded  com¬ 
ponent  relative  to  the  value  of  the  information  lost  to  that  user  and  to  the 
division  as  a  whole.  The  statistics  which  need  to  be  available  to  the  SYSCON 
in  order  to  estimate  the  decreases  in  utilization  of  the  overloaded  component 
obtained  by  decreasing  the  operating  level  of  one  or  more  users  are  given  in 
exhibit  3-4.  How  the  SYSCON  can  use  these  statistics  to  determine  which  user 
or  users  would  be  affected  and  the  level  of  decrease  necessary  in  order  to 
obtain  the  desired  reduction  in  utilization  is  discussed  in  subsection  3.3 
where  the  employment  of  management  procedures  is  discussed  in  the  context  of 
a  particular  component  overload. 


32 


33 


3.2.3  PROCEDURE  III:  PURGING 


Purging  removes  outdated  and  irrelevant  records  from  the  data  base.  Con¬ 
tinually,  existing  records  are  updated  and  other  records  are  manually  purged 
as  new  and/or  more  accurate  data  are  obtained.  From  correlations,  thresholds, 
and  filters,  records  are  manually  summarized  or  eliminated.  Querying  provides 
users  with  the  capability  to  retrieve  information  from  the  data  base.  With 
that  information,  the  battlefield  is  assessed,  plans  are  made,  etc.  During 
this  constant  use  and  review  of  the  data  base,  redundant,  irrelevant,  and 
inaccurate  records  should  be  identified,  and  users  would  be  expected  to  delete 
them. 


The  maintenance  of  TOS  files  may  require  that  additional  records  be  de¬ 
leted  to  ensure  the  quality  of  the  files  and,  more  important  operationally, 
to  ensure  that  the  data  base  does  not  become  overloaded  and  that  there  is 
storage  available  for  new  messages  as  necessary.  The  SYSCON  will  advise  file 
managers  of  the  technical  constraints  on  the  growth  of  files,  and  in  response 
to  estimates  of  the  future  size  of  files,  file  manan^-"  are  expected  to  purge 
their  files.  The  individual  characteristics  of  each  .sill  determine 

exactly  what  data  in  the  files  are  candidates  for  puru  considering  their 

timeliness  and  relevancy  to  the  battlefield  situation,  yet  the  methods  of 
purging  can  be  standard  for  all  files.  Three  methods  of  purging — automatic, 
routine,  and  "as  required" — have  been  identified  as  means  to  manage  the  size 
of  the  TOS  data  base.  Individual  divisions  and  their  file  managers  should 
adapt  some  form  or  combination  of  these  methods  to  meet  unique  local 
requirements . 

The  automatic  purge  is  a  query  or  set  of  queries  stored  in  the  Preloaded 
Message  (PLM)  file  which  is  automatically  implemented  periodically  to  search 
the  Enemy  Situation  Data  ( FSD)  file.  Messages  matching  the  cruery  criteria 
are  deleted.  The  frequency  of  the  search  and  the  criteria  on  which  to  base 
the  search  are  defined  by  the  ENSIT  files  manager.  The  prime  candidates 
for  deletion  by  this  method  are  those  records  whose  validity  depends  on  time, 
since  implementation  of  the  automatic  purge  is  periodic.  The  age  at  which  the 
message  becomes  outdated  can  vary  for  each  automatic  purge  query  established. 

The  routine  purge  requires  pen  c  review  of  selected  data  records  and 
the  deletion  of  unneeded  data  in  quantities  great  enough  to  maintain  a  satis¬ 
factory  operational  system.  Although  the  frequency  of  review  depends  on  the 
file  manager  and  the  file,  routinely,  file  managers  or  delegated  users  should 
query  the  data  base  to  delete  records  which  have  become  irrelevant  due  to  time 
and  retrieve  and  review  for  deletion  records  which  are  otherwise  no  longer 
useful.  The  criteria  on  which  data  are  purged  reflect  a  combination  of  the 
commander's  information  needs  and  the  system  status.  Deleted  records  will 
have  been  judged  too  costly  (in  terms  of  use  of  storage  space)  to  keep  in  the 
data  base.  Not  only  will  this  reduce  the  size  of  the  files  but  also  aid  in 
maintaining  the  quality  of  the  data  base. 

"As  Required"  purging  is  determined  by  system  monitoring.  This  purge 
should  be  implemented  only  when  there  is  an  indication  that  a  file  size  is 
too  large  or  an  indication  of  an  impending  overload  which  reouires  the  file(s) 
to  be  reduced.  The  need  to  purge  could  result  from  a  change  in  the  message 
input  rate,  operating  level,  tactical  situation,  etc.,  which  was  not  known 


at  the  last  scheduled  routine  purge.  The  SYSCON  should  direct  the  appropriate 
file  manager  to  reduce  the  size  of  the  data  file.  The  system  status  will  dic¬ 
tate  the  volume  of  data  needed  to  be  purged  to  circumvent  or  rectify  the  over¬ 
load.  The  records  to  be  purged  can  be  obtained  by  calling  a  stored  query,  or 
by  constructing  an  ad  hoc  query  to  be  certain  the  number  of  records  retrieved 
is  sufficient  to  meet  the  required  volume  reduction.  The  selected  records  can 
be  automatically  deleted  or  reviewed  for  possible  deletion. 

Purging  can  be  based  on  one,  all  or  any  combination  of  the  three  methods. 
The  continual  automatic  and  periodic  purges  are  effective  in  maintaining  a 
data  base  of  quality  information  which  is  likely  to  impact  system  users.  The 
primary  system  effect  of  purging  is  on  the  size  of  the  data  base.  The  SYSCON 
and  file  managers  need  to  know  the  size  and  growth  rate  of  each  file  so  that 
when  the  data  base  is  to  be  purged,  a  purge  can  be  implemented  such  that  the 

data  base  is  returned  to  an  acceptable  size  with  minimal  impact  on  the  quality 

of  the  holdings.  "As  required"  purging  is  done  when  special  needs  are  to  be 
met  or  as  unrecognized  growth  in  the  data  base  has  caused  the  storage  to  be 
overloaded.  The  SYSCON  needs  to  monitor  the  size  of  each  of  the  files  and 
alert  the  file  manager(s)  as  to  when  they  are  becoming  too  large.  Further, 
the  SYSCON  and  file  manager(s)  will  need  to  be  aware  of  the  amounts  and  types 
of  messages  contained  in  these  files  in  order  to  be  sure  that  the  purge  is 
effective  and  timely  in  reducing  an  overload  state. 

An  indirect  effect  of  purging  the  contents  of  data  base  files  is  a  reduc¬ 
tion  in  the  amount  of  output  generated  via  correlations,  thresholds,  queries, 
etc.  This  effect  should  be  minimal  if  the  purge  is  automatic  or  routine, 

as  the  information  which  is  deleted  is  likely  to  be  no  longer  useful  and  con¬ 

sequently  not  included  by  the  retrieval  criteria.  In  the  case  of  an  "as  re¬ 
quired"  purge,  the  effect  could  be  significant. 


3.2.4  PROCEDURE  IV:  REMOVAL  OF  A  USER  FROM  A  DISTRIBUTION  LIST 

Distribution  lists  (D/L)  provide  TOS  users  who  wish  to  send  messages  to 
a  variety  of  users  with  a  means  to  do  so  without  having  to  type  the  destina¬ 
tion  code  for  each  user.  A  D/L  contains  as  many  as  20  destinations  and  is 
given  a  unique  name  by  which  it  is  identified.  The  D/L  are  created  and  modi¬ 
fied  only  by  the  SYSCON  and  file  manager(s)  and  therefore  it  is  easy  for  the 
SYSCON  to  control  and  monitor  who  is  contained  on  each  D/L. 

Users  should  be  kept  aware  of  the  distribution  lists  which  are  available 
and  the  subscribers  to  the  lists  so  that  when  they  are  used  the  message  is 
sent  to  those  users  who  need  the  information  and  only  them.  Misuse  or  abuse 
of  the  D/L  may  occur  if  the  lists  change  often  or  if  users  are  not  careful 
to  choose  a  D/L  which  contains,  as  nearly  as  possible,  only  those  users  who 
need  the  message.  Otherwise,  the  result  can  be  an  overload  of  many  users 
because  they  receive  irrelevant  messages  or  an  overload  of  the  communica¬ 
tions  net  because  of  the  unnecessary  output  propagated  by  these  lists.  A 
problem  with  controlling  the  type  and  amount  of  output  propogated  by  D/L  is 
that  the  receivers  are  not  in  control  of  what  is  sent  to  them;  the  origina¬ 
tor  of  the  message  enters  the  D/L  name  and  the  message  is  automatically 
distributed. 
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The  characteristics  of  the  construction  and  use  of  D/L  make  them  effective 
in  addressing  problems  of  overloads,  whether  or  not  they  are  identified  as  the 
root  cause  of  a  problem.  The  SYSCON  can  remove  a  destination  address  from  one 
or  more  D/L  in  order  to  reduce  the  DCC  output  load,  most  likely  resulting  in  a 
reduction  of  the  demand  placed  on  users  to  assimilate  the  output  messages,  the 
communication  links  over  which  the  messages  travel,  and  some  of  the  computer 
processors. ^  The  magnitude  of  the  effect  on  a  user  is  dependent  on  the  fre¬ 
quency  with  which  he  would  receive  messages  via  the  D/L  from  which  he  is  to 
be  removed.  The  effect  on  the  communications  net  over  which  those  messages 
would  be  transmitted  depends  on  the  frequency  and  the  length  of  the  messages. 
The  only  computer  processor  which  is  affected  by  the  use  of  D/L  is  the  message 
disk  controller  which  will  write  the  message  to  the  message  disk  for  every 
user  to  whom  it  is  sent.  The  magnitude  of  the  effect  is  therefore  dependent 
on  the  frequency  with  which  the  D/L  from  which  the  user  is  to  be  removed  is 
entered  in  the  distribution  field  of  a  message. 

The  information  quality  issues  are  primarily  limited  to  the  value  of  the 
messages  the  user  receives  via  the  D/L  from  which  he  is  to  be  removed.  If 
only  particular  types  of  messages  received  via  D/L  are  of  value  to  a  particu¬ 
lar  user,  the  originators  of  those  messages  can  be  advised  of  the  change  and 
have  that  user  identified  explicitly  as  a  destination.  Alternatively,  the 
user  could  submit  an  SRI  which  will  screen  those  messages  for  him. 

In  order  to  employ  this  management  procedure  effectively,  the  statistics 
which  are  given  in  exhibit  3-5  need  to  be  available  to  the  SYSCON.  Depending 
on  the  component  which  is  overloaded,  the  SYSCON  would  need  to  determine  which 
user  or  users  should  be  removed  from  which  D/L  in  order  to  be  assured  the 
necessary  amount  of  utilization  reduction  would  be  attained  once  the  procedure 
is  implemented. 


3.2.5  PROCEDURE  V:  HIERARCHICAL  REVIEW 

The  hierarchical  review  process  allows  the  brigade  element  to  review, 
for  possible  alteration  or  deletion,  messages  originating  at  a  subordinate 
battalion.  If  a  message  is  changed  or  deleted,  a  copy  of  the  message  is  sent 
to  the  originator.  Hierarchical  review,  therefore,  may  be  a  contributor  to 
an  overload  problem  as  well  as  a  procedure  to  circumvent  a  problem.  The  pro¬ 
cess  reduces  demands  placed  on  the  communications  link  between  the  DCC  and  the 
BDE,  as  some  messages  may  be  deleted  by  the  review.  Consequently,  the  demands 
on  the  computer  processors  are  also  reduced  as  the  arrival  rate  of  messages 
is  decreased.  Alternatively,  the  communications  net  between  BN  and  BDE  are 
further  burdened  by  hierarchical  review  due  to  the  notification  sent  to  the 
originators  of  deleted  or  altered  messages.  Therefore,  altering  a  hierarchi¬ 
cal  review  practice  may  be  helpful  in  addressing  an  overload  problem. 


■^The  demands  placed  on  the  computer  processor  by  the  use  of  D/L  on  mes¬ 
sages  is  dependent  on  the  design  of  the  system  software.  The  assumption 
made  in  this  analysis  can  be  used  only  for  illustration  of  possible  impacts. 
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EXHIBIT  3-5:  MONITOR  STATISTICS  FOR  CONTROL  OF  DISTRIBUTION  LISTS 


USER 


OUTPUTS  TO  USER 


DISTRIBUTION  LIST  (X  IF  USER-CONTAINED) 


NUMBER 

NO.  RECD. 

1 

2 

— 

3 

B 

5 

6 

RECEIVED 

VIA  D/L 

1 


Depending  on  the  component  which  is  overloaded,  the  review  procedure  may 
be  altered  to  increase  or  decrease  the  frequency  with  which  messages  are  to  be 
reviewed.  In  order  to  determine  if  the  procedure  would  be  effective  in  ad¬ 
dressing  a  problem,  the  SYSCON  would  need  to  know  the  frequency  at  which  the 
messages  originating  at  BN  are  reviewed  at  BDE  (for  each  BDE),  the  frequency 
at  which  those  messages  are  changed,  and  the  frequency  at  which  they  are  de¬ 
leted.  The  magnitude  of  the  effect  of  implementing  the  procedure  on  the 
utilization  of  BDE-BN  and  the  BDE-DCC  communications  nets  depends  on  the 
amount  of  increase  or  decrease  in  the  frequency  of  messages  reviewed,  the 
length  of  the  response  to  the  originating  BN  when  a  message  is  altered  or 
deleted,  and  the  length  of  the  original  message.  The  magnitude  of  the  effect 
on  the  computer  processors  depends  on  the  increase  or  decrease  in  the  infre¬ 
quency  at  which  messages  are  reviewed  and  the  types  of  message  which  are  ef¬ 
fected  (queries,  additions,  etc.). 

Before  a  current  hierarchical  review  practice  is  altered,  the  SYSCON 
should  consider  the  "side  effects"  of  the  alteration.  With  respect  to  quan¬ 
tity,  the  SYSCON  should  realize  that  an  alteration  to  decrease  demand  on  the 
BDE  to  DCC  communications  net  increases  the  demand  from  the  BDE  to  BN  and  vice 
versa.  With  respect  to  quality,  the  hierarchical  review  process  increases  the 
quality  of  messages  in  the  system  by  providing  for  more  complete  and  accurate 
information.  Any  attempt  to  decrease  the  level  of  hierarchical  review  may  have 
as  its  consequence  a  degradation  in  the  quality  of  the  information  received  at 
division  and  can  have  a  variety  of  impacts  on  other  users  of  that  data  (e.g., 
increased  purging  to  delete  the  “poor"  information,  increased  querying  to 
verify  the  information  obtained,  etc.). 

3.3  INFORMATION  MANAGEMENT  PROBLEMS 

The  procedures  discussed  in  the  preceding  section  are  tools  the  SYSCON 
can  use  to  control  the  quantity  of  information  transmitted  and  stored  by  TOS. 
The  purpose  of  these  procedures  is  to  reduce  an  overload  at  a  component  of 
TOS.  The  components  which  have  been  identified  as  the  most  vulnerable  to  an 
overload  are  the  communication  links  (especially  FM  and  multichannel),  the 
computer  processors  (particularly  the  message  disk  controller  and  the  data 
disk  controller),  and  the  data  base  disk  storage. 

Depending  on  the  component  which  is  overloaded,  the  SYSCON  would  have  a 
choice  within  the  set  of  five  management  procedures  for  a  procedure(s)  which 
could  best  alleviate  the  problem.  For  example,  a  storage  overload  is  perhaps 
most  quickly  alleviated  by  purging,  but  also  may  be  resolved  by  decreasing 
the  operating  levels  of  users.  The  choice  among  these  procedures  as  to  which 
are  most  effective  depends  on  the  circumstances  causing  the  overload,  the  con¬ 
sequences  of  the  overload,  the  current  battlefield  situation,  and  the  role  of 
TOS  in  supporting  the  mission.  Consequently,  the  SYSCON  must  have  knowledge 
of  all  of  these  factors  and  be  able  to  determine  the  effects  of  each  procedure 
on  the  overloaded  component  as  well  as  the  effects  on  success  of  the  mission 
and  the  satisfaction  of  the  users. 
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The  purpose  of  this  section  is  to  describe  problems  which  may  occur  and 
how  to  determine  which  procedure  is  most  effective  in  circumventing  which 
problem.  It  is  assumed  that  the  SYSCON  can  monitor  all  the  statistics  'men¬ 
tioned  in  the  previous  section,^"®  and  that  he  has  knowledge  of  each  user's 
role  in  the  battle.  This  allows  the  SYSCON  to  make  effective  TOS  management 
decisions  which  are  in  the  best  interests  of  the  division. 

The  problems  and  associated  management  solutions  are  described  in  four 
subsections  depending  on  the  system  component  involved.  In  subsection  3.3.1, 
communication  net  overloads  are  discussed,  and  the  example  used  is  an  over¬ 
load  of  an  FM  link  between  BDE  to  BN.  Subsections  3.3.2  and  3.3.3  address 
overloads  of  computer-related  components:  the  computer  processors  and  disk 
storage.  Control  of  an  overload  of  the  data  disk  controller  is  used  as  the 
example  pertaining  to  a  computer  processor  overload.  Finally,  in  subsection 
3.3.4,  management  in  response  to  an  overload  of  a  TOS  user  is  described. 

For  each  problem,  the  management  procedures  are  identified  which  may  be  ef¬ 
fective  in  addressing  the  problem.  Then,  by  considering  the  conditions  caus¬ 
ing  the  overload,  the  effectiveness  of  these  management  procedures  in  dealing 
with  the  overload  is  determined  in  terms  of  reducing  the  utilization  of  the 
component  (quantity).  Finally,  the  implications  of  each  of  these  management 
procedures  on  the  quality  of  information  and  on  the  permitted  user  access  to 
TOS  are  overlaid  on  the  quantity  impact  in  order  to  decide  which  management 
procedure(s)  to  employ.  By  stepping  through  the  analysis  example  for  each 
of  these  problems,  the  considerations  which  are  necessary  to  make  effective 
management  decisions  should  become  evident  and  can  then  be  applied  to  other 
component  overload  problems. 


3.3.1  COMMUNICATIONS  NETS 

The  supporting  communications  for  TOS  are  the  FM  and  multichannel  nets 
and  the  cable  links  over  which  messages  are  transmitted  from  a  TOS  user  I/O 
device  to  the  computing  center  and  vice  versa.  An  overload  on  a  communica¬ 
tions  net  will  likely  increase  the  length  of  time  a  user  waits  for  a  response 
to  a  query  or  decrease  the  rate  at  which  he  receives  messages  from  other  users 
If  the  net  which  is  overloaded  is  his  own,  the  TOS  user  may  experience  an  in¬ 
crease  in  receipt  of  NAK  (nonacknowledgements)  or  extreme  difficulty  in  obtain 
ing  the  net  for  transmitting  messages.  This  frustrates  the  user  because  TOS 
cannot  meet  his  demands,  and  when  it  does,  the  response  is  untimely. 

A  communications  overload  is  due  to  a  demand  on  the  communications  net 
to  transmit  more  messages  than  it  can  support.  The  source  of  those  messages 
may  be  direct  inputs  (update  and  query)  from  a  user,  responses  to  informa¬ 
tion  retrieval  requests,  or  relay  messages  among  subdivided  users.  Also,  com¬ 
munications  nets  are  susceptible  to  transmission  errors  caused  by  electronic 
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This  assumption  is  the  central  topic  of  chapter  4.0 
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countermeasures,  environmental  noise,  and  hardware  errors.  This  greatly  af¬ 
fects  net  capacity  (the  ability  to  transmit  messages  correctly)  and,  con¬ 
sequently.  the  communications  system  may  be  unable  to  support  even  modest 
demands. 

The  management  procedures  which  are  most  likely  to  be  effective  in  dealing 
with  a  problem  of  communications  overload  are  procedures  I,  II,  and  IV  above, 
specifically,  control  of  the  number  of  Information  Retrieval  Requests,  Operat¬ 
ing  Levels,  and  Removal  of  a  User  from  a  D/L.  In  the  case  of  a  BDE  FM  communi¬ 
cations  net,  procedure  V — Hierarchical  Review--may  also  be  effective  in  dealing 
with  some  problems  of  overload.  Once  the  overload  is  identified,  the  SYSCON 
must  quickly  analyze  the  situation  and  implement  the  appropriate  management 
procedures  to  circumvent  the  problem. 

Given  that  the  SYSCON  has  knowledge  of  the  contribution  to  the  overload 
of  each  transmitter-receiver  pair  utilizing  the  net,  the  types  of  messages 
which  compose  the  load,  the  importance  of  each  user's  access  to  TOS  and  to 
the  success  of  the  mission,  and  the  importance  of  each  type  of  message  to  the 
users,  he  can  determine  the  impact  of  implementing  each  of  the  management 
procedures  on  the  utilization  of  the  overloaded  component  and  on  the  infor¬ 
mation  needs  of  the  users  whom  the  procedure  would  effect.  The  SYSCON  then 
must  decide  on  and  implement  the  appropriate  procedure  or  procedures. ^ 


An  Example:  Overload  Of  A  BDE-BN  FM  Net 


For  this  example  consider  that  an  overload  of  a  BDE-BN  FM  net  has  been 
identified.  The  configuration  of  this  net  is  given  in  exhibit  3-6.  The  net 
is  shared  by  eight  transmitter-receiver  pairs,  one  at  each  battalion  and  four 
at  brigade.  The  SYSCON  is  assumed  to  have  available  the  statistics  given  in 
exhibits  3-7  and  3-8  which  characterize  the  utilizations  of  each  of  the  users 
(transmitter-receiver  pairs)  who  access  the  net. 

Imagine  that  the  SYSCON  has  determined  that  the  utilization  of  this  net 
should  be  maintained  at  or  below  0.700.  From  the  figures  in  exhibit  3-8, 
the  current  utilization  has  been  measured  at  0.859  with  the  three  maneuver 
battalions  contributing  over  80  percent  of  this  utilization.  Observe  from 


^Capacity  here  is  defined  as  in  chapter  2.0:  "Component  capacity  is  the 
traffic  rate  which  results  in  80  percent  utilization." 
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For  a  further  discussion  of  these  effects  see  ARI  Working  Notes  80-12 
described  in  the  preface. 
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It  is  possible  that  circumstances  may  exist  for  which  the  SYSCON  decides 
it  is  best  to  do  nothing  and  let  the  communications  net  continue  in  the 
overloaded  state. 

22 

The  means  by  which  these  statistics  are  made  available  is  not  yet  known, 
but  it  is  assumed  that  if  they  are  not  automatically  generated  the  SYSCON 
can  either  query  the  system  or  the  users  for  the  information. 
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EXHIBIT  3-7:  EXAMPLE  LOADINGS  ON  THE  TOS  COMPONENTS  OF  A  BRIGADE 


2b  4  30/10  f  2b/5 


EXHIBIT  3-8:  CALCULATED  UTILIZATIONS  OF  . 

BDE-BN  FM  COMMUNICATIONS  LINKS1 


LINKS  UTILIZING  BDE-BN  FM  NET 

- - - - - ■ - ■  - - —  -  ■  — 

UTILIZATION  OF  NET 

BN1  Transmissions  to  BDE 

0.198 

BDE  Transmissions  to  BN1 

0.042 

BN2  Transmissions  to  BDE 

0.198 

BDE  Transmissions  to  BN2 

0.042 

BN3  Transmissions  to  BDE 

0.177 

BDE  Transmissions  to  BN2 

0.048 

!  DS  BN  Transmissions  to  BDE 

1 

0.132 

BDE  Transmissions  to  BN3 

0.025 

TOTAL  BN  Transmissions  to  BDE 

0.703 

TOTAL  BDE  Transmissions  to  BN 

0.156 

TOTAL 

0.859 
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exhibit  3-7  that  the  types  of  messages  which  comprise  this  utilization  are 
primarily  input  messages  (queries  and  updates)  as  indicated  by  the  utiliza¬ 
tion  of  the  brigade  FM  communications  net  for  transmitting  messages  originat¬ 
ing  at  the  subordinate  battalion. 

From  the  statistics  assumed  to  be  available  to  the  SYSCON  as  given  in  ex¬ 
hibit  3-7,  the  potential  for  each  management  procedure  to  decrease  the  utiliza¬ 
tion  of  the  brigade  FM  net  can  be  calculated  and  is  given  in  exhibit  3-9. 2^*24 
This  potential  is  the  maximum  decrease  in  utilization  which  could  be  achieved 
by  a  given  procedure  if  it  were  invoked  to  its  limit,  for  example,  if  the 
operating  level  of  every  user  were  reduced  to  level  D  (0  updates  and  0  queries). 
In  terms  of  quantity  only,  the  most  precipitously  effective  management  proce¬ 
dure  would  be  to  change  the  operating  level  of  all  users  to  level  D  which 
would  result  in  a  decrease  of  0.703.  The  management  procedure  which  has  the 
least  potential  for  rectifying  the  overload  problem  is  altering  the  hierarchi¬ 
cal  review  such  that  no  messages  are  reviewed  (i.e.,  no  messages  are  deleted 
or  altered  and  therefore,  no  notification  is  sent  to  the  originators).  Also 
shown  in  exhibit  3-9  is  the  potential  decrease  which  can  be  obtained  if  the 
procedure  is  applied  to  only  one  of  the  battalion.  A  detailed  explanation 
of  exhibit  3-9  and  its  impact  on  the  example  is  in  order.  Referring  to  the 
exhibit,  a  number  shown  in  parentheses  in  the  "total"  column  is  the  decrease 
in  utilization  which  can  be  achieved  per  "unit"  change  in  the  management  pro¬ 
cedure,  where  "unit"  is  defined  with  respect  to  the  management  procedure.  In 
the  case  of  the  first  management  procedure,  the  "unit"  is  one  IMR  request — SRI, 
THRESHOLD,  CORRELATION,  OR  FILTER.  The  load  statistics  given  in  exhibit  3-7 
show  that  each  MAN  BN  has  two  SRI  in  the  system  and  receives  nine  responses 
per  hour  and  that  the  DS  BN  has  two  SRI  and  receives  one  response  per  hour 
(a  total  of  eight  SRI  requests  and  28  SRI  responses  from  the  four  battalions). 
From  exhibit  3-9  the  utilization  of  the  net  due  to  these  28  responses  has  been 
estimated  to  be  0.037.  If  one  of  these  SRI  requests  were  eliminated,  an  ex¬ 
pected  3.5  (28/8)  responses  would  be  eliminated  and  a  0.004  (0.037/8)  decrease 
in  utilization  would  be  achieved. 

The  "unit"  for  management  procedure  II  is  one  query  or  update  message. 

To  determine  the  expected  effect  of  decreasing  the  operating  level,  the  de¬ 
crease  in  the  number  of  queries  and  update  messages  to  be  expected  need  to  be 
computed  and  then  multiplied  by  the  value  of  each  of  these  "units."  For  exam¬ 
ple,  if  the  operating  level  of  BN1  was  reduced  from  level  A  to  level  B,  nine 
updates  (from  39  to  30  in  exhibit  3-7)  and  one  query  (from  six  to  five)  would 
be  eliminated  per  hour,  reducing  the  utilization  of  the  net  by  0.044  (10  X 
0.0044,  the  latter  factor  shown  rounded  off  to  0.004  in  exhibit  3-9). 


O'! 

The  equations  for  calculating  the  utilization  of  the  net  based  on  the  moni¬ 
tored  statistics  given  in  exhibit  3-7  are  given  in  the  appendix.  It  is  not 
useful  to  present  them  in  this  discussion  as  they  are  lengthy  and  cumbersome. 
It  is  the  opinion  of  the  authors  that  in  reality  the  SYSCON  will  not  be  able 
to  perform  these  calculations  and  that  a  Design/Decision  Aid  (computerized) 
will  need  to  be  used. 

^Exhibit  3-7  gives  the  monitor  statistics  which  are  directly  applicable  to 
the  BDE-BN  FM  net.  The  SYSCON  will  also  need  to  have  knowledge  of  the  sta¬ 
tistics  discussed  in  section  3-2  and  given  in  exhibits  3-3  and  3-5. 
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EXHIBIT  3-9:  QUANTITATIVE  EFFECT  OF  MANAGEMENT 

PROCEDURES  ON  EXAMPLE  BRIGADE  FM  NET 


MANAGEMENT 

PROCEDURE 


I.  Reduce  IMR 
Requests 

II.  Change 
Operating 
Level 

III.  Purge 


DECREASE  IN-  UTILIZATION  FRACTION* 


TOTAL 


.037 

(.004) 

.703 

(.004) 


IV.  Remove  User 
From  D/L 

V.  Alter 

Hierarchical 


e 


Not  Applicable 
to  Communica¬ 
tion  Problem 

.063 

(.004) 

.013 

(.001) 


BN1 

>  -  ■ 

BN2 

[  BN3 

DS  BN 

.012 

.012 

.012 

.001 

.198 

.198 

.177 

.132 

i 

.018 

.018 

.018 

.009 

.002 

.002 

Kt* 

o 

o 

.005 

*Sum  may  not  add  to  total  due  to  rounding. 


For  procedure  IV,  the  unit  is  one  D/L  address.  The  utilization  of  the 
net  due  to  update  response  messages  received  by  D/L  has  been  determined  to  be 
0.063  as  shown  in  exhibit  3-9.  The  MAN  BNs  are  on  four  D/L  and  the  DS  BN  is 
on  two  D/L  resulting  in  a  total  of  39  update  response  messages  (determined 
as  the  sum  of  the  update  response  messages  being  received  via  D/L  as  indicated 
in  exhibit  3-7)  to  be  received  by  these  BNs.  From  these  statistics,  the  de¬ 
crease  in  utilization  which  can  be  expected  by  the  removal  of  one  BN  from 
one  D/L  can  be  determined  and  is  estimated  to  be  0.004  (0.063/14;  where  14 
is  the  total  number  of  D/L  subscribed  by  each  BN — 3x4  +  1x2 ) . 

Finally,  the  "unit”  for  Hierarchical  Review  is  one  reviewed  message. 

For  the  case  described,  26  messages  per  hour  are  currently  changed  during 
review.  If  the  review  procedure  were  altered  such  that  only  25  messages 
were  changed,  the  decrease  in  utilization  is  estimated  to  be  0.001  (0.013/26, 
actually  0.0005,  rounded  off  to  0.001  in  exhibit  3-9). 

By  the  use  of  these  figures  the  SYSCON  can  determine  which  management 
procedure  or  procedures  he  can  implement  to  achieve  the  desired  decrease  in 
utilization.  For  example,  he  can  decrease  the  operating  level  of  each  of  the 
four  battalion  users  by  one  level  and  achieve  a  total  decrease  in  utilization 
of  0.16  (a  reduction  of  25  messages  at  an  estimated  value  of  0.004  each).  The 
SYSCON  can  also  selectively  place  the  third  maneuver  BN  and  the  support  BN  at 
level  C  and  remove  the  first  and  second  maneuver  BN  from  one  D/L  and  achieve 
a  similar  decrease  in  the  utilization.  Observe  also  that  the  required  0.159 
reduction  in  utilization  cannot  be  achieved  without  reducing  the  operating 
level  of  one  or  more  of  the  battalion  subscribers.  Eliminating  all  IMR  re¬ 
quests  (0.037),  abandoning  all  hierarchical  review  (0.013),  and  removing  all 
battalions  as  D/L  members  (0.063)  could  achieve  only  a  reduction  of  0.113, 
still  short  of  the  required  0.159. 

The  selection  of  an  appropriate  alternative  requires  that  the  SYSCON  have 
knowledge  of  the  value  to  each  BN  of  each  type  of  information  received  and  also 
the  value  to  other  TOS  users  in  the  division  of  the  information  provided  by 
these  BNs.  If,  for  example,  the  SYSCON  knows  that  the  first  and  second  maneu¬ 
ver  BN  are  in  active  contact  with  the  enemy,  then  they  are  likely  providing 
reports  which  are  of  value  to  BDE  and  division  commanders  and  a  reduction  in 
their  access  to  send  information  is  not  appropriate.  Also,  if  it  is  known 
that  the  responses  received  via  the  SRI  are  of  high  value  to  the  BNs,  then 
a  reduction  of  those  SRI  as  a  means  to  achieve  the  non-overloaded  state  would 
not  be  acceptable. 

With  his  assessment  of  the  battlefield  situation,  the  SYSCON  must  decide 
how  to  change  the  overload  state  of  the  communications  net.  For  the  purpose 
of  example,  suppose  that  the  SYSCON  perceives  that  the  third  maneuver  and 
support  BN  can  be  placed  at  operating  level  C,  achieving  a  reduction  of  0.160 
in  the  utilization  of  the  net.  In  addition,  all  the  hierarchical  review  could 
be  eliminated,  since  the  message  now  being  sent  from  these  two  units  should  be 
equivalent  to  the  most  complete  and  accurate  of  the  previous  set,  and  the 
messages  sent  from  the  first  and  second  MAN  BNs  are  generally  of  high  quality. 
This  would  decrease  the  utilization  of  the  net  further  and  possibly  increase 
the  rate  at  which  the  net  returns  to  a  satisfactory  state. 


The  procedure  for  choosing  the  appropriate  management  action  is  clearly 
not  methodical  and  obviously  complicated.  The  SYSCON  will  likely  find  such 
management  difficult,  but  rather  than  taking  a  "shot  in  the  dark,"  the  statis¬ 
tics  which  should  be  made  available  to  him  allow  him  to  have  confidence  in 
his  management  action  that  the  overload  will  be  corrected.  The  more  the 
SYSCON  knows  about  the  battlefield  situation  and  each  user's  role  in  the  mis¬ 
sion,  the  more  likely  the  choice  of  which  management  procedure  to  employ  will 
be  simpler  and  acceptable  to  the  affected  users.  If  the  SYSCON' s  knowledge 
does  not  allow  him  to  make  effective  management  decisions,  then  each  user  may 
need  to  be  involved  in  the  process  and  the  SYSCON  would  be  responsible  for 
coordinating  the  effort  to  ensure  that  the  necessary  reduction  in  utilization 
is  achieved. 


3.3.2  COMPUTER  PROCESSORS 

The  computer  processors  are  the  hardware  devices  which  act  on  jobs  (the 
basic  information-handling  activities  visible  to  a  user,  e.g.,  updating  a  file) 
as  they  are  routed  through  the  Division  Computing  Center  (DCC),  e.g.,  the  front 
end  processor  or  the  message  disk  controller.  Analysis  of  the  computer  proc¬ 
essor  components  has  shown  that  the  message  disk  controller  and  the  data  disk 
controller  are  the  only  processors  which  have  potential  overload  problems. 
Therefore,  any  further  reference  to  computer  processors  refers  to  these  con¬ 
trollers  specifically. 

An  overload  of  the  computer  processors  may  occur  because  of  a  hardware 
or  software  failure  or  because  of  excessive  demands  placed  on  the  system. 
Computer  system  diagnostics  and  maintenance  procedures  and  fault  detection 
and  isolation  functions  are  available  to  identify  and  correct  hardware  and 
software  problems,  but  management  procedures  are  necessary  to  deal  with  the 
information  needs  of  TOS  users  between  the  time  of  failure  and  correction. 

Also,  if  trie  failure  is  planned,  for  example,  a  system  shut-down  for  displace¬ 
ment,  management  procedures  are  necessary  to  allow  users  to  prepare  for  the 
shut-down  and  to  deal  with  the  outage.  In  all  cases,  though,  upon  restora¬ 
tion  of  the  lost  capability,  TOS  users  can  be  expected  to  make  inordinate 
demands  on  the  system,  both  to  provide  and  to  obtain  information.  Management 
procedures  are  necessary  to  deal  with  this  situation  because  these  peaks  in 
demands  on  the  system  may  be  so  great  as  to  cause  substantial  delays  in  proc¬ 
essing  and  possibly  a  system  crash.  Also,  TOS  users  could  possibly  overload 
the  system  duriny  normal  operations  by  placing  excessive  demands  on  the  sys¬ 
tem.  "Covering  all  bases"  by  extensive  querying  or  submitting  broad  range 
or  large  numbers  of  SRI  can  be  disastrous  as  was  experienced  in  FM-222.  If 
old  information  (data  records)  and  outdated  information  retrieval  requests 
are  not  purged  from  the  system,  a  system  overload  may  occur  simply  because 
the  size  of  the  data  base  which  must  be  searched  and  the  number  of  jobs  that 
must  be  served  are  beyond  the  processor's  capacity.  Management  procedures 
to  deal  with  these  problems  must  limit  the  number,  and  possibly  the  type, 
of  information  retrieval  requests  a  user  makes,  prioritize  the  input  of  new 
information  in  times  of  high  system  use,  and  motivate  users  to  purge  old  in¬ 
formation  and  data  requests. 
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The  management  procedures  which  are  most  likely  to  be  effective  in  deal¬ 
ing  with  problems  of  overloaded  computer  processors  are  those  that  limit  the 
number  of  jobs  the  processor  must  perform.  These  are  procedures  I  and  II 
which  limit  the  number  of  information  retrieval  requests  and  the  number  of 
inputs  and  queries  (operating  levels),  respectively.^  Once  an  overload  of 
a  computer  processor  is  identified,  the  SYSCON  .would  have  to  analyze  the  po¬ 
tential  of  each  of  these  management  procedures  to  reduce  the  utilization  of 
the  disk  controller.  Then  by  judging  the  impact  of  each  procedure  on  the 
quality  of  information  processed  by  the  system,  he  would  decide  how  this 
would  be  accomplished.  If,  for  example,  it  were  decided  that  reducing  the 
number  of  thresholds  and  correlations  would  be  effective,  determining  which 
ones  to  delete  would  be  dependent  on  the  value  to  the  users  of  the  informa¬ 
tion  retrieved  by  these  requests.  In  the  following  example,  consider  that 
an  overload  of  the  data  disk  controller  has  been  identified  and  that  the 
SYSCON  will  need  to  decide  quickly  on  the  appropriate  management  action. 

Again,  as  in  the  case  of  an  overload  of  a  communications  net,  the  SYSCON  is 
assumed  to  have  knowledge  of  the  types  of  messages  by  function  and  by  origina¬ 
tion  which  compose  the  load  on  the  processors,  the  value  of  each  user's  ac¬ 
cess  to  TOS  to  the  success  of  the  mission,  and  the  importance  of  each  type 
of  message  to  the  users. 

AN  EXAMPLE:  OVERLOAD  OF  THE  DATA  DISK  CONTROLLER 

The  jobs  performed  by  the  data  disk  controller  are  to  read  and  write 
messages  and  other  data  from  the  data  disk.  Any  incoming  message,  except 
relays,  will  task  the  data  disk  controller  either  to  add  a  new  message  to 
the  data  base,  or  to  search  keys  and  key  values  for  particular  types  of  mes¬ 
sages.  For  this  example  assume  that  the  SYSCON  has  determined  that  the  utili¬ 
zation  of  the  data  disk  controller  should  be  kept  at  or  below  0.600  for  safe 
and  satisfactory  system  operation.  The  monitor  statistics  available  to  the 
SYSCON,  given  in  exhibits  3-10  and  3-11,  indicate  that  the  utilization  of  the 
data  disk  controller  is  above  this  value  and  it  is  necessary  that  he  invoke 
management  controls.  From  these,  the  SYSCON  can  estimate  the  potential  for 


25 

The  configuration  of  the  software  design  analyzed  in  the  study  assumed  that 
the  message  disk  controller  would  write  a  copy  of  a  response  message  to  the 
message  disk  for  each  user  to  whom  it  is  to  be  sent.  In  this  case,  the  re¬ 
moval  of  a  user  from  a  distribution  list  may  also  be  an  effective  management 
procedure . 
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The  jobs  performed  by  the  data  disk  controller  and  the  procedure  by  which 
they  are  accomplished  is  dependent  on  the  hardware  and  software  design.  Since 
these  were  not  firm  at  the  time  TOS  project  work  halted,  a  design  was  assumed 
based  on  available  documentation  so  that  overloads  which  might  occur  and  the 
impact  of  management  procedures  to  correct  these  problems  could  be  examined. 

^7The  factors  affecting  the  value  of  utilization  at  which  a  TOS  component 
should  be  identified  as  overloaded  are  discussed  in  detail  in  chapter  4.0. 


EXHIBIT  3-10:  EXAMPLE  LOADINGS  ON  THE  DATA  DISK  CONTROLLER 


♦Circle  Indicates  Current  Operating  Level  **No  Bound  on  Use 


EXHIBIT  3-10:  EXAMPLE  LOADINGS  ON  THE  DATA  DISK  CONTROLLER  (Continued) 


^Circle  Indicates  Current  Operating  Level  **No  Bound  on  Use 


EXHIBIT  3-11:  CALCULATED  UTILIZATIONS  OF  DATA  DISK  CONTROLLER 


From  the  example  loadings  given  in  exhibit  3-10. 


each  of  the  management  procedures  to  decrease  the  utilization  of  this  con¬ 
troller  as  shown  in  exhibit  3-12. 28  in  parentheses  are  the  gradiants  of 
these  decreases.  For  example,  if  one  SRI  is  eliminated  the  expected  decrease 
in  utilization  of  the  data  disk  controller  is  0.0020. 

In  the  case  of  operating  levels,  if  they  are  changed  such  that  one  less 
update  message  is  eliminated,  the  expected  decrease  in  utilization  is  0.006. 
From  the  information  in  exhibit  3-12  it  is  apparent  that  a  reduction  in 
operating  level  holds  the  most  potential  for  a  decrease  in  utilization  as  no 
processing  is  performed  by  the  data  disk  controller  if  no  demands  are  made. 
This  level  of  decrease  is  likely  unnecessary  and  not  satisfactory  to  any  user 
although  from  the  monitor  statistics  available  to  the  SYSCON  and  shown  in  ex¬ 
hibit  3-10,  the  SYSCON  could  selectively  place  users  at  lower  operating  level 
such  that  the  necessary  decrease  in  utilization  is  achieved.  For  example, 
decreasing  the  operating  level  of  the  ENG  BN  and  CAV  SQN  to  level  C  and  the 
operating  level  of  the  three  man  BNs  of  BDE1  to  level  B  the  decrease  in 
operating  level  would  be  0.0762.^  The  management  procedure  which  produces 
the  greatest  effect  per  unit  decrease  in  access  is  elimination  of  filter 
requests.  Yet  there  are  so  few  filters,  it  is  likely  that  the  necessary 
decrease  in  utilization  can  not  be  obtained  by  eliminating  filters  only  and 
still  maintain  user  satisfaction  with  the  decreased  access. 

Now,  based  on  his  knowledge  of  the  user's  information  needs,  the  SYSCON 
would  have  to  decide  the  appropriate  management  procedure  to  employ.  Assume 
that  in  the  SYSCON' s  judgment  the  access  permitted  by  the  current  operating 
level  of  each  user  is  at  or  below  the  level  at  which  the  information  require¬ 
ments  of  the  division  are  met;  therefore,  changing  operating  levels  would  not 
be  considered  appropriate  management  action.  This  leaves  the  reduction  of 
the  number  of  incoming  message  retrieval  requests  as  the  only  alternative  ac¬ 
tion.  Without  extensive  information  as  to  the  specific  characteristics  of 
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The  calculations  necessary  to  make  these  estimates  are  lengthy  and  cumber¬ 
some,  yet  they  are  necessary  for  ensuring  that  the  management  action  which 
is  taken  is  effective  in  returning  the  component  to  a  non-over loaded  state. 
Ihe  equations  utilizing  the  monitored  statistics  given  in  exhibit  3-10  are 
given  in  the  appendix.  It  is  believed  that  the  SYSCON  will  need  a  decision 
aid  (computerized  or  a  series  of  tables)  in  order  to  make  these  estimates 
in  a  short  time. 
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The  calculations  necessary  to  make  this  estimate  are  as  follows: 


Decrease  in  updates: 

ENG  BN: 

58  -  40 

= 

18 

Current  load  - 

CAV-SQN : 

148  -  50 

= 

98 

New  Operating  level  load: 

MAN  BNs: 

( 32-30 ) x3 

= 

6 

TOTAL: 

122 

Decrease  in  queries: 

ENG  BN: 

5-5 

= 

0 

Current  load  - 

CAV  SQN: 

9-5 

= 

4 

New  operating  level 

MAN  BNs: 

( 7-5 ) x3 

= 

6 

TOTAL: 

10 

Decrease  in  utilization:  (122x0.0006)  +  (10x0.0003)  =  0.0762 

(Decrease  in  load  x  gradient) 


EXHIBIT  3-12:  QUANTITATIVE  EFFECT  OF  MANAGEMENT 
PROCEDURES  ON  DATA  DISK  CONTROLLER 
CALCULATED  FROM  EXAMPLE  LOADINGS 


MANAGEMENT  PROCEDURE 

DECREASE  IN  UTILIZATION 
(Gradiant  of  Decrease  in  Utilization) 

1 .  Reduce  IMR  Requests 

0.5198 

SRI 

0.1970  (0.0020) 

Threshol d 

0.11 08  (0.0022) 

Ccrrel ation 

0.0910  (0.0018)  i 

Filter 

0.1210  (0.00^8) 

2.  Change  Operating  Level 

o 

o 

Updates 

. ^ (0.0006)  ; 

Queries 

. 1  (0.0003)  1 

3.  Purge 

1 

Not  Applicable  ; 

l 

4.  Remove  User  from  D/L 

Not  Aopl i cable 

5.  Alter  Hierarchical  Review 

i 

Not  Appl icafcl e 

The  operating  level  control  procedure  does  not  permit  the  recuction 
of  updates  and  queries  separately;  therefore,  it  is  not  reasonable 
to  estimate  tne  ootential  of  each  of  these  to  reduce  tne  utilization, 
of  the  data  cis!<  controller. 
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each  of  these  requests,  it  is  difficult  to  determine  which  ones  are  burden¬ 
ing  the  system;  for  example,  by  being  triggered  often  or  invoking  a  query 
which  has  many  key  values  specified  and  consequently  requires  many  searches 
of  the  inverted  key  buffer,  etc.30  One  option  for  the  SYSCON  is  to  set  a 
time  frame  or  specific  user  as  a  qualifier  on  the  commands  to  eliminate  spe¬ 
cific  requests.  In  the  event  that  a  valuable  request  is  eliminated,  the 
originator  (who  is  automatically  notified  of  deletion)  might  then  delete  a 
less  valuable  request  and  replace  it  with  the  one  selected  for  elimination 
by  the  SYSCON.  To  obtain  any  information  he  may  have  missed,  the  user  may 
also  choose  to  query  the  data  base.31  Since  the  utilization  of  the  data 
disk  controller  needs  to  be  decreased  by  0.1003  (exhibit  3-10),  an  across- 
the-board  20  percent  decrease  in  incoming  message  retrieval  requests — 20  SRI, 
10  THRESH,  10  CORR,  and  5  FILTERS — would  achieve  the  desired  effect  (0.5198  x 
0.20).  Alternatively  eliminating  11  FILTERS  and  25  SRI  is  also  sufficient  to 
return  the  processor  to  a  non-over loaded  state  [(25  x  0.0020)  +  (11  x  0.0048)] 
As  stated  in  subsection  3.2.1,  the  decision  depends  on  the  value  to  the  users 
of  the  information  received  by  these  functions  and  the  effects  on  the  quality 
and  quantity  of  messages  stored  in  the  data  base  by  eliminating  correlations, 
thresholds,  and  filters. 


3.3.3  COMPUTER  STORAGE  OVERLOAD 

A  storage  overload  is  characterized  by  the  saturation  of  any  of  the 
memory  buffers,  e.g.,  the  disks  or  core  memories.  The  saturation  may  occur 
because  of  an  overgrown  data  base,  a  communications  net  failure  (the  messages 
to  be  transmitted  on  the  net  are  stored  in  buffers),  or  a  user  overload  (the 
messages  which  are  sent  to  a  user  are  stored  in  core  at  his  terminal  until 
he  has  the  time  to  review  them).  A  storage  overload  at  the  DCC,  in  all  prob¬ 
ability,  will  keep  the  DCC  from  processing  information  in  a  timely  manner 
and  users  will  experience  long  delays  in  the  receipt  of  information.  Also, 
depending  on  the  design  of  the  system  software,  the  saturation  of  particular 
buffers  may  result  in  a  lockout  of  the  receipt  or  transmittal  of  information 


30In  this  case,  it  is  obvious  that  the  users  may  be  in  better  position  to 
implement  the  management  procedure  than  the  SYSCON.  For  example,  if  it  were 
determined  that  elimination  of  10  percent  of  the  incoming  message  retrieval 
requests  would  produce  the  required  results,  then  each  user  could  be  directed 
to  do  so,  likely  resulting  in  increased  satisfaction  of  the  users  as  they 
are  able  to  choose  which  requests  are  eliminated. 

31Since  it  is  difficult  to  determine  the  decrease  in  utilization  achieved 
by  eliminating  these  requests  as  the  probability  they  are  triggered,  the 
search  criteria,  etc.,  may  be  very  different  from  request  to  request,  it 
may  be  necessary  that  more  requests  than  are  determined  necessary  are  deleted 
to  increase  the  likelihood  that  a  non-overloaded  state  is  actually  obtained. 
The  impact  of  this  decrease  in  access  on  other  forms  of  utilization  of  the 
system  (e.g.,  more  querying  or  replacing  requests  not  useful  with  those 
eliminated)  is  also  difficult  to  assess  and  another  reason  the  number  of 
requests  eliminated  might  need  to  be  more  than  the  number  determined 
necessary. 
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or  perhaps  the  destruction  of  part  of  the  operating  system.  Due  to  the  catas¬ 
trophic  nature  of  this  problem,  management  procedures  are  necessary  to  prevent 
the  possibility  of  the  saturation  of  any  of  the  buffers. 

One  management  procedure  to  prevent  the  occurrence  of  an  overload  is  to 
monitor  the  rate  of  incoming  messages,  to  estimate  the  expected  time  until 
saturation  of  the  buffers,  and  then  to  decrease  the  arrival  rate  as  necessary. 
Another  management  procedure  is  to  purge  the  data  base  to  prevent  the  disk 
from  becoming  saturated.  This  procedure  must  include  preventative  as  well 
as  "as  required"  methods  for  purging,  as  the  time  and  processing  necessary 
for  purging  place  a  burden  on  the  users  and  the  system.  In  response  to  an 
identified  buffer  overload  if  the  condition  is  due  to  the  overload  of  another 
component,  a  decrease  in  the  utilization  of  the  other  component  will  decrease 
the  utilization  of  the  associated  buffer. 

An  attempt  to  store  too  many  data  records  in  the  disk  files  exemplifies 
the  case  in  which  a  storage  overload  is  not  the  result  of  another  overload. 

In  this  situation,  management  procedures  which  decrease  the  amount  of  infor¬ 
mation  stored  are  effective.  An  increase  in  the  number  of  correlations  and 
thresholds,  and  a  decrease  in  the  rate  of  incoming  messages  (changes  in  operat¬ 
ing  level)  are  likely  to  be  effective  but  also  are  likely  to  be  slow  in  cor¬ 
recting  the  problem.  The  most  effective  management  procedure  is  purging, 
particularly  "as  required"  purging.  The  SYSCON  should  continually  monitor 
the  utilization  of  the  data  base  disk  storage  and  advise  the  file  managers 
when  they  are  overloaded.  The  SYSCON  would  also  need  to  advise  the  file  man¬ 
ager  of  the  amount  of  reduction  necessary  in  order  to  return  the  file  to  the 
desired  size.  The  file  manager  would  then  be  responsible  for  constructing 
the  purge  queries  to  meet  both  the  battlefield  situation  and  the  TOS  system 
requirements.  The  file  manager  must  also  choose  between  deleting  the  records 
without  review  or  reviewing  each  record  to  decide  if  it  should  be  deleted. 

Such  decision  would  likely  be  based  on  the  time  which  is  available  to  con¬ 
duct  the  purge  and  the  types  of  records  which  are  to  be  deleted. 

3.3.4  USER  OVERLOAD 

A  user  is  considered  overloaded  if:  (1)  he  is  required  to  compose  and 

transmit  more  messages  in  a  period  of  time  than  he  is  physically  or  mentally 
able;  (2)  he  receives  more  information  than  he  is  able  to  assimilate  in  a 
period  of  time;  (3)  he  receives  unreasonable  amounts  of  outdated  or  useless 
information  which  he  must  separate  from  the  timely  and  useful  information; 
or  (4)  any  combination  of  the  three  tasks  above  beyond  his  capabilities.  A 
user  overload  is  not  as  readily  identifiable  as  other  components  as  it  is  not 
easy  to  define  a  user's  capacity.  Guidelines  could  be  set  up  which  might 
indicate  a  possible  overload;  for  example,  if  the  weighted  sum  of  the  number 
of  input  and  output  messages  is  beyond  some  tb-eshold,  then  the  user  is  as¬ 
sumed  to  be  overloaded.  Certainly,  every  individual  has  a  different  capacity 
to  process  information  and  what  is  an  overload  for  one  person  might  well  be 
a  comfortable  load  for  another.  A  user  overload  is  very  dependent  on  each 
user's  individual  capabilities  as  well  as  his  functions  in  addition  to  in¬ 
teracting  with  TOS,  and  very  difficult  for  the  SYSCON  to  manage  effectively. 

The  user  can  and  will  likely  handle  the  situation  himself  if  he  feels  over¬ 
tasked,  as  he  can  request  to  be  removed  from  D/L  or  eliminate  some  of  the 


incoming  message  retrieval  requests  to  reduce  the  amount  of  output  he  receives. 
Further,  he  can  reduce  the  number  of  query  messages  and  updates  submitted. 

The  problem  of  a  user  overload  is  best  addressed  then  by  providing  the  user 
with:  (1)  advice  of  information  constraints  (message  types  and  subjects  not 

currently  wanted  by  the  commander  and  his  staff)  and  information  needs  (mes¬ 
sage  types  and  subjects  in  demand);  (2)  guidelines  for  message  preparation — 
particularly  the  definition  of  data  entries  for  which  there  is  no  DED  entry, 
free  text  fields  and  descriptions;  and  (3)  default  distribution  lists  defining 
to  whom  to  send  the  information  if  the  originator  is  unsure  of  who  may  be 
interested. 

The  TOS  user  is  the  most  critical  component  of  the  TOS  system  and  suc¬ 
cess  of  the  system  ultimately  lies  in  his  satisfaction.  It  is  therefore 
necessary  that  he  understand  what  TOS  can  do  for  him  and  how  he  is  to  use 
the  system  to  perform  these  tasks.  All  information  management  procedures 
should  work  together  such  that  the  TOS  user  can  most  effectively  use  the 
capabilities  without  feeling  restricted  or  unnecessarily  burdened. 


4.0  PROCEDURES  FOR  DETECTING  A  TOS  SYSTEM  OVERLOAD 


An  entire  procedure  for  managing  a  TOS  system  overload  can  be  depicted 
as  in  exhibit  4-1.  Chapter  3.0  discussed  steps  2-4,  specifically  the  alter¬ 
native  actions  (management  procedures)  available  to  the  SYSCON  and  methods 
to  analyze  the  overload  in  order  to  decide  on  the  appropriate  management  ac¬ 
tion.  This  chapter  addresses  the  procedure  for  detecting  an  overload  includ¬ 
ing  the  considerations  which  are  necessary  before  an  exact  definition  of  a 
component  overload  can  be  recommended.  In  the  event  an  overload  cannot  be 
identified  by  automated  means,  an  example  of  a  process  for  detecting  an  over¬ 
load  is  also  developed. In  section  4.1  the  factors  which  impact  the  defini¬ 
tion  of  an  overload  are  discussed.  Then,  in  section  4.2,  a  definition  of  an 
overload  and  procedures  for  identifying  the  overload  are  developed  using  the 
CAV  SQN  FM  communications  net  as  an  example  because  an  operational  definition 
of  an  overload  and  procedures  for  identifying  an  overload  are  dependent  on 
the  component  itself.  In  the  final  section  of  this  chapter,  the  monitoring 
of  the  system  described  in  chapter  3.0  and  in  the  first  sections  of  this 
chapter  are  summarized  to  indicate  the  range  of  parameters  characterizing  the 
TOS  system  which  need  to  be  available  to  the  SYSCON  in  order  to  control  the 
system  effectively. 


4.1  THE  CONSIDERATIONS  FOR  DEFINING  A  COMPONENT  OVERLOAD 

The  term  overload  is  used  in  chapter  3.0  to  identify  when  the  SYSCON 
needs  to  take  management  action  to  ensure  that  the  TOS  system  remains  respon¬ 
sive  to  user  needs  and  that  a  system  crash  is  avoided.  This  overload  refers  to 
a  state  of  the  component  where  its  utilization  is  above  some  desired  threshold. 
The  determination  of  the  appropriate  threshold  value  is  complex  and  needs  to 
consider  three  basic  factors:  (1)  the  responsiveness  that  is  required  of  the 
system;  (2)  the  means  by  which  the  utilization  of  the  component  is  measured; 
and  (3)  the  procedures  which  are  available  to  circumvent  the  problem. 

The  responsiveness  that  is  required  of  the  system  includes  the  utiliza¬ 
tion  which  can  be  tolerated  by  the  hardware  and  software  without  causing  a 
system  crash  and  the  utilization  which  can  be  tolerated  by  the  users  inter¬ 
facing  the  system.  A  definition  of  overload  suggested  by  the  concept  of 
operational  capacity  presented  in  chapter  2.0  considered  primarily  these 
requirements.  Operational  capacity  is  defined  as  the  demand  which  produces 
a  utilization  of  80  percent.  The  analysis  indicating  this  value  showed  that 
at  utilization  of  greater  than  80  percent  the  expected  waiting  time  and  ex¬ 
pected  queue  length  quickly  exceed  the  system  requirements  given  in  the  A- 
and  B-level  specifications.  Further,  it  acknowledges  that  at  utilizations 
of  less  than  80  percent,  control  of  demand  is  a  nearly  linear  control  for 
expected  delay.  This  analysis  suggests  that  an  upper  bound  on  the  threshold 
is  0.8  utilization. 
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The  design  of  the  hardware  and  software  for  the  computer  system  will  de¬ 
termine  the  extent  to  which  the  detection  of  an  overload  is  automatic. 

4 


EXHIBIT  4- 


:  PROCEDURE  FOR  MANAGING  A  TOS  SYSTEM  OVERLOAD 
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Factors  which  might  necessitate  that  this  threshold  be  lower  are  the 
means  by  which  the  utilization  of  the  component  is  measured.  If  the  utili¬ 
zation  is  computed  automatically  by  computerized  monitoring  of  busy  and 
non-busy  periods,  then  the  primary  concern  is  the  period  of  time  over  which 
the  utilization  is  measured  or  the  integration  period.  If  the  period  is 
too  short,  sporadic  increases  in  system  use  might  be  observed  and  the  net 
will  be  incorrectly  identified  as  congested,  whereas,  if  the  integration 
period  is  too  long,  the  net  may  have  become  overloaded  but  measurement  of 
the  overload  is  masked  by  the  adjacent  periods  where  the  utilization  was 
low.  Gi'en  the  integration  period,  the  utilization  threshold  value  can  be 
set,  sucn  that  the  occurrence  of  these  errors  is  minimized.  If  the  utiliza¬ 
tion  must  he  measured  by  some  other  more  manual  means,  concerns  such  as  the 
degree  to  which  accurate  data  on  the  use  of  the  system  can  be  obtained,  and 
the  amount  of  manual  effort  required  to  calculate  the  utilization  become 
important  when  determining  the  appropriate  value  of  the  threshold.  In  chap¬ 
ter  3.0  the  utilization  of  the  computer  processor  is  measured  as  the  number 
of  times  a  processor  must  perform  different  tasks  in  a  given  time  interval 
multiplied  by  the  length  of  time  it  takes  to  perform  each  task  divided  by 
the  time  interval.  The  utilization  of  the  communications  link  is  measured 
as  the  number  of  messages  that  travel  over  that  link  in  a  given  period  of 
time  times  the  length  in  characters  of  those  messages  divided  by  the  number 
of  characters  that  link  can  transmit  in  a  given  period  of  time.  If  the 
burden  this  monitoring  places  on  the  SYSCON  is  too  great,  the  threshold 
value  might  need  to  be  set  much  lower  than  the  requirement  set  by  considera¬ 
tions  of  responsiveness  only  so  that  the  SYSCON  does  not  need  to  be  con¬ 
stantly  concerned  as  to  whether  a  system  crash  is  imminent. 

The  third  factor  influencing  the  appropriate  value  of  the  threshold  is 
the  quantitative  relationship  between  the  cause  of  the  problem  and  the  pro¬ 
cedure  for  correcting  the  problem.  For  example,  if  a  disk  processor  is  being 
tasked  to  perform  more  jobs  than  it  can  handle,  an  appropriate  management 
procedure  might  be  to  reduce  the  number  of  jobs  arriving  at  the  processor. 

The  time  it  takes  to  complete  each  job,  the  number  of  jobs  "backlogged," 
the  time  it  takes  to  implement  the  management  procedure  and  the  new  rate 
at  which  jobs  are  arriving  all  impact  the  time  it  takes  for  the  processor 
to  return  to  a  state  where  jobs  are  being  processed  in  a  timely  manner.  In 
determining  the  appropriate  value  of  the  threshold,  these  kinds  of  factors 
must  be  considered  so  that  a  system  disaster  is  not  incurred  between  the 
time  the  overload  is  detected  and  the  time  the  effects  of  the  management 
action  are  seen. 

These  three  factors  are  basic  for  determining  the  value  of  the  threshold 
for  identifying  the  overloaded  state  of  any  component  but  the  actual  value 
which  is  appropriate  for  a  specific  component  depends  on  the  operating  char¬ 
acteristics  of  the  component  itself.  As  an  illustration,  in  the  next  section 
the  CAV  SQN  FM  net  is  considered.  The  factors  specific  to  determining  the 
appropriate  threshold  value  for  this  component  are  discussed.  Also  included 
is  an  example  of  how  the  SYSCON  could  determine  the  utilization  of  the  com¬ 
ponent  in  the  absence  of  automated  detection.  Given  are  the  monitor  statis¬ 
tics  which  need  to  be  available  and  the  calculations  which  need  to  be  made 
in  order  to  estimate  the  utilization  of  the  net. 


59 


4.2  AN  ILLUSTRATION;  DETERMINATION  OF  AN  OVERLOAD  OF  THE  CAV  SQN 

FM  NETS 

The  analysis  of  the  TOS  system  has  shown  that  the  FM  communications  nets 
are  likely  to  cause  long  delays  in  the  transmission  of  messages.  Those  long 
delays  are  due  to  a  demand  by  TOS  users  to  transmit  information  over  these 
nets  in  excess  of  the  net  capacity.  To  prevent  these  delays  the  use  of  the 
FM  nets  can  be  monitored  such  that  when  delays  are  likely  to  become  unaccept¬ 
able,  control  procedures  are  implemented  to  prevent  this  from  occurring.  The 
first  task,  therefore,  is  to  determine  when  the  net  is  being  overutilized  or 
overloaded  and,  secondly,  to  determine  which  control  procedure  to  implement 
to  alleviate  the  situation.  Chapter  3.0,  particularly  subsection  3.3.2,  dis¬ 
cusses  the  second  of  these  two  tasks  and  the  previous  section  presents  basic 
considerations  affecting  the  appropriate  definition  of  an  overload.  In  the 
following  paragraphs,  two  other  considerations  unique  to  the  communications 
nets  are  discussed;  then  an  example  of  how  the  SYSCON  would  detect  an  overload 
is  presented.  The  two  additional  factors  unique  to  an  overload  of  communica¬ 
tions  nets  are  related  to  the  user  requirements  factor  given  in  section  4.1: 

(1)  the  user  interface  and  (2)  the  battlefield  situation.  The  CAV  SQN  FM 
net  is  used  as  the  example  component  for  describing  how  an  overload  could 
be  detected  manually  if  it  cannot  be  detected  by  automated  means. 

The  first  factor,  user  interface,  considers  the  demands  placed  on  the 
user  at  different  levels  of  utilization  of  the  net.  For  example,  without  any 
automatic  transmission  of  the  messages,  if  the  net  is  utilized  80  percent  of 
time,  a  user  would  experience  a  "busy  signal”  80  percent  of  the  time  he  tried 
to  access  the  net.  However,  in  TOS,  the  transmitter  will  automatically  try 
three  successive  times  to  access  the  net.  If  the  net  is  not  obtained,  the 
transmission  attempt  is  terminated  and  the  user  is  notified.33  No  further 
automatic  processing  occurs  until  the  operator’s  instructions  are  received. 

The  long  delays  associated  with  human  decisionmaking  and  response  make  it 
imperative  that  the  human  role  in  data  transmission  be  minimized.  Further, 
the  burden  placed  on  the  operator  by  these  requests  for  instructions  may  lead 
to  rejection  and  hence  failure  of  the  system.  Exhibit  4-2  depicts  the  prob¬ 
ability  that  the  operator  is  told  the  line  is  busy  as  a  function  of  the  time 
between  automatic  retries  to  obtain  the  line.34  At  best,  at  80  percent  utili¬ 
zation  the  user  will  be  told  that  the  line  is  busy  approximately  50  percent 
of  the  time.  If  this  is  unacceptable  with  respect  to  human  factor  considera¬ 
tions,  then  the  utilization  threshold  may  need  to  be  set  lower  than  80  percent. 


33 

In  addition,  the  user  is  notified  if  the  line  is  obtained  but  errors  in 
transmission  caused  the  message  to  be  received  incorrectly  three  times.  See 
Volume  III:  Analysis  of  the  Tactical  Operations  System. 

34The  time  between  automatic  retries  to  access  the  net  by  the  transmitter 
is  important  to  the  success  of  the  transmitter  to  access  the  net  as  seen 
by  the  graph,  but  this  is  fixed  by  the  hardware  and  software  design  and 
not  subject  to  management  action. 
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The  second  factor,  battlefield  situation,  refers  to  conditions  which  occur 
on  the  battlefield  when  a  commander  needs  to  have  complete  or  a  very  high 
probability  of  access  to  the  communications  net,  or  where  a  short  response 
time  to  queries  or  incoming  message  retrieval  requests  is  demanded  by  a  com¬ 
mander.  These  changes  in  requirements  for  access  would  be  considered  temporary 
and  in  response  to  particular  battlefield  conditions.  For  such  situations  the 
utilization  threshold  may  need  to  be  decreased  to  insure  that  the  access  which 
is  needed  is  realized  by  the  commander. 

With  the  conditions  determined  for  when  a  net  is  identified  as  overloaded, 
the  SYSCON  can  use  this  guideline  to  determine  when  the  employment  of  manage¬ 
ment  controls  are  necessary.  The  SYSCON  is  responsible  for  monitoring  the  FM 
nets  and  determining  the  state  of  overload.  The  simplest  way  would  be  to  have 
automatic  monitoring  of  the  net  to  determine  the  utilization,  and  once  the 
threshold  is  exceeded,  the  SYSCON  would  be  notified,  either  by  a  warning  mes¬ 
sage  or  signal.  Barring  any  sort  of  automation  the  SYSCON  is  still  able  to 
estimate  the  utilization  of  the  communications  net.  The  data  which  needs  to 
be  available  to  the  SYSCON  are  given  in  exhibit  4-3  and  are  obtained  by  count¬ 
ing  both  the  total  number  of  times  the  user  attempted  to  get  a  line  and  the 
number  of  times  the  user  attempted  but  found  it  busy  for  the  integration  pe¬ 
riod.  These  figures  are  obtained  at  the  transmitter  of  each  transmitter- 
receiver  pair.  For  the  case  of  the  CAV  SQN  FM  net,  only  two  pairs  utilize 
the  net,  one  at  the  DCC  and  one  at  the  CAV  SQN,  whereas  the  BDE-BN  FM  net 
would  have  8  pairs — 1  pair  each  BN  (with  the  transmitter  at  BN)  and  4  effec¬ 
tive  pairs  at  the  BDE  level  (with  the  receivers  at  BN).  Then  the  SYSCON 
would  need  to  make  the  calculations  given  in  exhibit  4-4.  This  procedure 
simply  estimates  the  utilization  by  sampling  the  line  (every  time  a  user 
wants  to  transmit  a  message)  and  calculating  the  fraction  of  time  it  was 
found  busy.  If  the  utilization  is  above  the  threshold  value  for  identifying 
a  component  as  overloaded,  the  SYSCON  would  then  need  to  obtain  the  data 
describing  the  cause  of  the  overload  and  take  the  appropriate  management 
action  as  described  in  chapter  3.0. 


4.3  MONITOR  STATISTICS  FOR  MANAGING  TOS 

The  monitor  statistics  described  in  chapter  3.0  and  in  the  previous 
section  of  this  chapter  can  be  characterized  into  two  basic  types:  those 
which  are  monitored  to  detect  a  component  overload  and  those  which  are  moni¬ 
tored  in  order  to  understand  how  to  rectify  the  overload  problem.  Within 
this  second  type  there  are  three  kinds  of  statistics:  those  which  describe 
how  each  type  of  demand  (update,  query,  etc.)  affects  each  type  of  component, 
those  which  describe  the  current  load  (demand)  on  each  component,  and  those 
which  measure  the  impact  of  the  load  on  each  component.  It  is  necessary  for 
the  SYSCON  to  have  available  to  him  statistics  of  each  kind  in  order  to  con¬ 
trol  the  system  effectively.  In  addition,  as  discussed  in  chapter  3.0,  he 
also  needs  to  have  knowledge  of  the  information  needs  of  each  user  of  TOS 
within  the  division  and  the  methods  by  which  these  users  obtain  their  infor¬ 
mation  needs  (e.g.,  queries  vs.  SRI)  for  ensuring  that  the  users  remain  satis¬ 
fied  with  the  management  control . 


EXHIBIT  4-3:  EXAMPLE  MONITOR  STATISTICS  TO  DETECT 
AN  OVERLOAD  OF  BDE-BN  FM  NET 

Frequency  that 

BDE  attempted  to  TRANSMIT 
BDE  got  a  BUSY  signal 

MAN  BN  1  attempted  to  TRANSMIT 
MAN  BN  1  got  a  BUSY  signal 

MAN  BN  2  attempted  to  TRANSMIT 
MAN  BN  2  got  a  BUSY  signal 

MAN  BN  3  attempted  to  TRANSMIT 
MAN  BN  3  got  a  BUSY  signal 

DS  BN  attempted  to  TRANSMIT 
DS  BN  got  a  BUSY  signal 


Iw*  &>***»• 


EXHIBIT  4-4:  CALCULATION  TO  ESTIMATE  UTILIZATION  OF  BDE-BN  FM  NET 


UTILIZATION 


Sum  of  Frequency  of  BUSY  Signals 
Sum  of  Attempts  to  TRANSMIT 
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The  monitor  statistics  which  are  needed  to  detect  an  overload  of  the 
system  are  dependent  on  the  degree  to  which  the  hardware  and  the  software 
of  the  system  automatically  monitor  the  status  (utilization)  of  each  compo¬ 
nent.  In  the  example  provided  in  section  4.2  the  data  which  are  collected 
are  used  to  estimate  the  utilization  of  a  brigade  FM  net  in  the  absence  of 
any  automatic  monitoring.  For  other  components  it  would  be  necessary  to 
develop  similar  surrogate  methods  for  monitoring  their  utilization  if  provi¬ 
sions  for  monitoring  are  not  included  in  the  hardware  and  software  designs. 

Once  overload  is  detected,  data  such  as  are  described  in  chapter  3.0 
need  to  be  used  to  determine  the  management  action  appropriate  for  rectifying 
the  overload.  The  example  loadings  given  in  exhibits  3-7  and  3-10  describe 
the  demands  placed  on  the  system;  in  particular,  those  related  to  the  bri¬ 
gade  communications  net  and  the  data  disk  controller  respectively.  In  addi¬ 
tion  to  monitoring  the  loadings,  the  SYSCON  needs  to  have  available  the 
operating  level  guidelines  defined  for  each  user  and  the  D/L  on  which  each 
user  is  a  member  in  order  to  manage  the  system  effectively.  These  monitor¬ 
ing  statistics  are  listed  again  for  reference  in  exhibit  4-5.  Other  statis¬ 
tics  which  need  to  be  monitored  are  those  which  describe  how  the  demands  (SRI, 
queries,  etc.)  impact  the  system.  These  statistics  are  exemplified  in  ex¬ 
hibit  3-3  for  the  IMR  requests,  but  it  is  also  necessary  that  similar  data 
be  available  for  queries  and  updates.  When  quantified,  these  statistics  de¬ 
scribe  the  expected  or  average  value  for  all  of  the  requests  of  a  particular 
type.  For  example,  the  frequency  with  which  the  IMR  criteria  of  the  SRI 
requests  are  satisfied  characterizes  all  the  SRI  requests  and  not  each  one 
individually.  Therefore,  when  these  statistics  are  used  to  calculate  the 
quantitative  effect  of  a  management  procedure,  the  result  is  an  estimate  of 
the  change  in  utilization  which  may  be  realized  by  implementing  these  pro¬ 
cedures.  Exhibit  4-6  lists  the  monitor  statistics  given  in  exhibit  3-3 
augmented  by  those  necessary  for  updates  and  queries.  A  combination  of  these 
statistics  and  the  loadings  allow  the  SYSCON  to  determine  the  utilization  of 
the  component  due  to  the  different  types  of  demand  and  the  effectiveness  of 
each  management  procedure  to  resolve  a  system  problem  once  identified.  The 
SYSCON  needs  to  be  kept  aware  of  the  sources  of  the  various  demands  which 
have  accumulated  and  the  extent  to  which  they  are  causing  a  component  to  be 
unduly  stressed  so  that  he  can  choose  the  control  procedures  most  appropriate 
for  dealing  with  that  situation. 

As  argued  in  chapter  1.0,  and  evidenced  here  by  the  number  and  variety 
of  items  which  must  be  monitored  in  order  for  the  SYSCON  to  control  the  sys¬ 
tem,  provision  for  monitoring  the  status  of  the  system  components  must  be 
included  in  the  hardware  and  software  designs.  Also  clear  is  the  relation¬ 
ship  between  the  two  major  considerations  governing  the  extent  to  which  the 
monitoring  capability  should  be  designed.  That  is,  if  the  magnitude  of 
the  management  task  becomes  too  large,  so  will  the  amount  of  information 
necessary  to  be  monitored,  and  vice  versa. 
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EXHIBIT  4-5:  EXAMPLE  MONITOR  STATISTICS  FOR  DETERMINING 
THE  LOADING  ON  TOS  COMPONENTS 


For  Each  User: 

IMR  Requests  Originated 
SRI 

THRESH 

CORR 

FILTER 

IMR  Responses  Received 
SRI 

THRESH 

CORR 

FILTER 

Updates  Originated 

Updates  Response  -  Total 

Update  Responses  -  Received  via  D/L 

D/L  a  Member  of 

Queries  Originated 

Messages  Altered  or  Deleted  by  Hierarchical  Review 
Operating  Level  Guidelines 
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EXHIBIT  4-6:  EXAMPLE  MONITOR  STATISTICS  FOR  DETERMINING 
THE  IMPACT  OF  DEMANDS  ON  TOS  COMPONENTS 

Demands:  Incoming  Message  Retrieval  Requests 

•  Number  of  SRI  on  the  System 

•  Frequency  that  IMR  criteria  for  SRI  are  checked 
(SRI)  •  Frequency  that  IMR  criteria  for  SRI  are  satisfied 

•  Distribution  of  SRI  response 

•  Length  of  SRI  responses 

•  Number  of  Threshold  queries  on  the  system 

•  Frequency  that  IMR  criteria  for  threshold  queries  are  checked 

•  Frequency  that  IMR  criteria  for  threshold  queries  are  satisfied 

(THRESH)  •  Frequency  that  threshold  criteria  are  satisfied 

•  Distribution  of  threshold  responses 

•  Length  of  threshold  response 

•  Average  number  of  keys  and  key  values  searched 

•  Number  of  correlations  in  the  system 

•  Frequency  that  IMR  criteria  for  correlations  are  checked 

•  Frequency  that  IMR  criteria  for  correlations  are  satisfied 

(CORR)  •  Average  number  of  queries  triggered 

•  Distribution  of  correlation  responses 

•  Length  of  correlation  responses 

•  Average  number  of  keys  and  key  values  searched 


Continued  — 


EXHIBIT  4-6:  EXAMPLE  MONITOR  STATISTICS  FOR  DETERMINING 

THE  IMPACT  OF  DEMANDS  ON  TOS  COMPONENTS  (Concluded) 

•  Number  of  filters  In  the  system 

•  Frequency  that  IMR  criteria  for  filters  are  checked 

•  Frequency  that  IMR  criteria  for  filters  are  satisfied 

•  Frequency  that  a  data  base  search  is  triggered 

(FILTER) 

•  Frequency  that  a  filter  response  is  required 

•  Distribution  of  filter  responses 

•  Length  of  filter  response 

•  Average  number  of  keys  and  key  values  searched 

Demand:  Update  Messages  (Add,  Change,  Delete) 

•  Frequency  that  messages  are  originated 

•  Distribution  of  messages  ty  type  (ESDA,  ESDC,  UTOD,  etc.) 

•  Length  of  message 

•  Number  of  keys  updated 

•  Distribution  associated  with  messages 

Demand:  Queries 

•  Frequency  that  queries  are  originated 

•  Length  of  query 

•  Distribution  of  query  response 

•  Length  of  query  response 

•  Number  of  keys  and  key  values  searched 
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APPENDIX:  EQUATIONS  FOR  DETERMINING  UTILIZATION 


Given  in  this  appendix  are  the  equations  used  in  this  analysis  for 
determining  the  utilization  of  each  of  the  TOS  components  discussed  in 
this  volume,  specifically  the  communications  nets,  the  message  disk 
driver,  and  the  data  disk  driver. 
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A.l  COMMUNICATION  NET 


UTILi 


£  £ 

j  k  ( NMSG j j k )  (LMSGk)  (XMITSk) 
CAP, 


Where: 


UTILi 
NMSG  -j  j  k 


LMSGk 

XMITSik 


CAPi 


Utilization  of  communication  net  i. 

Number  of  messages  of  type  k  sent  over  transmitter- 
receiver  pair  j  utilizing  the  communication  net  i  per 
hour. 

Length  of  message  type  k,  including  header  and  trailer, 
in  characters. 

Expected  number  of  times  message  type  k  must  be 

transmitted  to  be  received  correctly  over  communications 
net  i . 

The  capacity  of  communications  net  i  to  transmit  data  in 
characters  per  hour. 


and  XMITSik  =  1/(1  -  PERRORj  )BITSk  +  (BITSk)  (PERROR-j )  ( 1  -  PERRORj )  ( BITk  -  1.0) 
where: 


PERROR-j  =  Probability  a  bit  will  be  in  error  for  communications 
net  i . 

BITSk  =  Number  of  bits  in  message  type  k. 
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A. 2  MESSAGE  DISK  CONTROLLER 


UTIL  _  [2( SRIRSP  +  THRRSR  +  CORRSP  +  FILRSP  +  QRYRSP)  +  UPDRSPl 

CAP- 

Where: 

UTIL  =  Utilization  of  message  disk  controller 
SRIRSP  =  Number  of  SRI  responses  generated  per  hour 

THRRSP  =  Number  of  THRESHOLD  responses  generated  per  hour 

CORRSP  =  Number  of  CORRELATION  responses  generated  per  hour 

FILRSP  =  Number  of  FILTER  responses  generated  per  hour 

QRYRSP  =  Number  of  Query  responses  generated  per  hour 

IJPDRSP  =  Number  of  update  responses  generated  per  hour 

CAP  =  Service  rate  of  message  disk  controller, 

number  of  message  disk  reads/writes  which  can  be 
completed  per  hour. 


A. 3  DATA  DISK  CONTROLLER 


UTIL 


where 

SRICHK 

THRCHK 

THRTRG 

THRKEY 

VALKEY 

CORCHK 

CORTRG 


=  | SRICHK  +  THRCHK  +  (THRTRG) (THRKEY) (VALKEY)  +  CORRCHK 
+  [(C0RTRG)(C0RQRY)]  [ (CORKEY) (VALKEY)  +  CORREC] 

+  FILCHK  +  (FILTRG) (FILKEY) ( VALKEY) 

+  ADD  (1  +  2  (ADDKEY))  CHG  (2+2  (CHGKEY) ) 

+  DEL  (1  +  2  (CHGKEY)) 

+  (QRY)  [(QCYKEY)( VALKEY)  +  QRYREC]}  *  CAP 


=  Frequency  that  the  I  MR  criteria  of  the  SRI  are  checked 
against  incoming  messages,  number  per  hour. 

=  Frequency  that  the  IMR  criteria  of  the  THRESHOLD 
requests  are  checked  against  incoming  messages,  number 
per  hour. 

=  Frequency  that  the  THRESHOLD  query  is  triqgered,  number 
per  hour. 

=  Expected  number  of  keys  specified  by  THRESHOLD  query. 

=  Expected  number  of  key  values  searched  per  key  per  data 
base  search. 

=  Frequency  that  the  IMR  criteria  of  the  CORRELATION 
request  are  checked  against  incominq  messages,  number 
per  hour. 

=  Frequency  that  the  CORRELATION  is  triggered,  number  per 
hour. 
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CORQRY 

CORKEY 

CORREL 

FILCHK 

FIIKEY 

ADD 

ADDKEY 

CHG 

CHGKEY 

DEL 

DELKEY 

ORY 

QRYKEY 

ORYREC 

CAP 

and  VALKEY 
where: 

NKYVAL 


=  Average  number  of  queries  per  CORRELATION  request. 

=  Expected  number  of  keys  specified  by  CORRELATION  Query. 

=  Expected  number  of  records  retrieved  per  CORRELATION 
query. 

=  Frequency  that  the  I  MR  criteria  of  the  FILTER  requests 
are  checked  against  incoming  messages,  number  per  hour. 

=  Expected  number  of  keys  specified  by  FILTER  query. 

=  Frequency  that  messages  are  added  to  the  data  base, 
number  per  hour. 

=  Expected  number  of  keys  to  be  updated  by  the  addition  to 
the  data  base. 

=  Frequency  that  messages  in  the  data  base  are  chanqed, 
number  per  hour. 

=  Expected  number  of  keys  to  be  updated  by  the  change  to 
the  data  base. 

=  Freauency  that  messaaes  in  the  data  base  are  deleted, 
number  per  hour. 

=  Expected  number  of  keys  to  be  updated  by  the  deletion  of 
a  record  from  the  data  base. 

=  Frequency  that  the  daf base  is  queried  (by  QUERY 
requests),  number  per  hour. 

=  Expected  number  of  keys  specified  by  the  query. 

=  Expected  number  of  records  retrieved  per  query. 

=  Service  rate  of  data  disk  controller,  number  of  data 
disk  reads/writes  which  can  be  completed  Der  hour. 

=  L0G2  (NKYVAL) 


=  Expected  number  of  key  values  per  key. 
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